[alsa-devel] Fwd: Lynx HiLo USB DAC issues
Hello, I'm now an owner of a Lynx Hilo USB DAC/ADC. It is supposedly USB Audio Class 2 compatible, but it does require an advanced driver on both Windows and Mac OS X. The device has a complex UAC2 mixer and extra features.
It enumerates fine, but there's some problem with the clock selector and sink parameters. I've attached lsusb -vvv and dmesg output.
Apparently bNrInPins is invalid for the clock selector for some reason. After adding an extra log of that variable, I get: [49574.136478] __uac_clock_find_source(): selector reported illegal value, id 40, ret 6, pins 1
This can actually be correct if the current clock source is not supported via USB. HiLo has a separate clock source variant for USB.
I think that in this case, the clock shouldn't be rejected as invalid, instead switched to the available source if possible. During initialization, there can be any kind of garbage present in the selector.
Thanks for any help, -- Radosław Szkodziński
In fact, there's nothing linking bNrInPins with bClockID at all in the standard.
From what I could read, baCSourceID(I) contains the actual ClockID
that should be set, while the code does:
for (i = 1; i <= selector->bNrInPins; i++) { ... err = uac_clock_selector_set_val(chip, entity_id, i);
Setting it to the pin number instead of the clock ID.
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.
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 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.
Help from someone who has access to a more complex device is hence more than welcome :)
Thanks, Daniel
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 :)
On 12.09.2013 19:00, Radoslaw Szkodzinski wrote:
On Thu, Sep 12, 2013 at 6:41 PM, Daniel Mack zonque@gmail.com wrote:
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.)
We have SNDRV_PCM_RATE_CONTINUOUS which should be used in such cases, but how should the driver get to know about this feature if the device doesn't report it in any way?
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.
Yep, that certainly makes sense. I'm looking forward to your patches.
Thanks for your help, Daniel
participants (2)
-
Daniel Mack -
Radoslaw Szkodzinski