[alsa-devel] Lynx HiLo USB DAC issues

Daniel Mack zonque at gmail.com
Thu Sep 12 19:07:16 CEST 2013


On 12.09.2013 19:00, Radoslaw Szkodzinski wrote:
> On Thu, Sep 12, 2013 at 6:41 PM, Daniel Mack <zonque at 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



More information about the Alsa-devel mailing list