Re: Lynx HiLo USB DAC issues

[Daniel Mack <zonque@gmail.com>]

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