Hi,
when I implemented the basics for parsing the UAC2 clock functions, I came across some principal questions I would like to discuss.
As I wrote in the commit log, UAC2 supports a number of clock units which can be combined to complex topologies. The single unit types are
- clock sources (can be fixed, variable, programmable and synced to the USB clock) - clock switches, which let the host decide which one out of many input pins appears on its output pin - clock multipliers, which have a numerator and a denominator, and both can be read-only or read-write, respectively
A clock source has controls for its frequency and its validity, a clock selector has a control to control its current state, and a clock multiplier has controls for its numerator and denominator
The driver is currently able to walk the graph of connected units in order to find CLOCK_SOURCE descriptors as end-leafs. This is mandatory as all requests for sample rate queries have to be sent to this unit type.
This raises the first question, as the driver can only know which sample rates are supported in the currently selected combination of selectors. Once the user changes any of them (which is currently already possible as clock selectors are exported as mixer controls), everything can change. And this can even happen while the stream is active, because there's currently no check about whether the clock selector is part of the actively used path.
The second issue I see is that a clock can lose its validity. A real-life example is an external S/PDIF connected device which provides a clock and which is suddenly disconnected. Firmwares are expected to notify the host about such cases, and these messages are trivial to dispatch. However, I wonder how the driver should react on this. From a user's perspective, it would be best to just make the driver find another clock path which reports a valid clock source endpoint, changes the sample rate accordingly and continues streaming. There would be a gap in the stream of course, but at least it would not kill the applications or require major exception handling in userspace.
I wonder which approaches are actually possible to implement, which details in the ALSA core would need to be extended, and so on.
Any oppinions? Has this been done before for any other audio hardware supported by ALSA?
Thanks, Daniel