On Thu, Sep 12, 2013 at 6:41 PM, Daniel Mack zonque@gmail.com wrote:
Hi Radoslaw,
On 12.09.2013 02:43, Radoslaw Szkodzinski wrote:
Never mind, I see the issue now. (It is late here.) The CLOCK_SELECTOR is read-only according to lsusb output.
Apparently uac_clock_selector_get_val fails to work, returning invalid pin number. That should not happen, but it shouldn't be called either in this case, as the selector is irrelevant.
Sorry, I don't follow. Given that you successfully dug into the driver sources already, can you share a patch that makes things work for you?
The patch is not complete yet; I've done the selector fix, but it uncovered an issue where the device doesn't report any sample rates (CUR 0, RANGE 0) and ALSA is unable to handle this. I'll add some probing - this, unlike the broken selector, is technically allowed by UAC2 but a bit silly. (The device can handle anything 1 Hz to 384kHz. And DSD.)
The problem with the clocking framework in UAC2 is that it's quite powerful (there are multipliers, dividers, switches etc), but I haven't yet seen a system that actually makes uses it in more complex applications. Hence it's not exactly easy to come up with a generic approach of how to handle all the possible cases correctly, and how to react on clock validity loss for instance.
I've decided in that case (readonly invalid selector) to count the valid sources and if there's only one valid, use that.
Help from someone who has access to a more complex device is hence more than welcome :)