Caelia Chapin wrote:
> On Thu, Feb 23, 2017 at 5:47 AM, Clemens Ladisch <clemens@xxxxxxxxxx> wrote:
>> In sound/usb/clock.c, around line 192, try to remove this:
>>
>> if (validate && !uac_clock_source_is_valid(chip, entity_id)) {
>> usb_audio_err(chip,
>> "clock source %d is not valid, cannot use\n",
>> entity_id);
>> return -ENXIO;
>> }
>
> I presume the code I removed exists for a reason. Are there likely to be
> any adverse side effects from this kernel modification?
The worst case is that some other device actually does not have a valid
clock source, and that the driver does attempt to send samples anyway,
which will then silently fail.
As long as the driver cannot automatically select another valid clock
source, it might be a better idea to ignore this.
> Can you state definitively that failing to respond to the clock source
> query is incorrect behavior?
This device does not fail to _respond_ to the query, it _does_ respond,
and the response says "I cannot play at the moment".
Or it is missing the descriptor for the clock source. Please re-add
the code (but remove the "return -ENXIO;"), and add logging to check
whether it is the first "if (!cs_desc)" at the beginning of the
uac_clock_source_is_valid() function that aborts, or if this function
runs through to the end. If it cannot find that descriptor, please
show the output of "lsusb -v" for this device.
In either case, this would be a definitive error of the firmware.
Regards,
Clemens
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Alsa-user mailing list
Alsa-user@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-user
