Garnet MacPhee wrote:
Clemens Ladisch wrote:
I've got several reports that devices no longer work since UAC2 support got added. But I've just noticed this is not related to the interface class but to the interface protocol: the new code added checks for UAC_VERSION_1 or _2, but real devices apparently write just random junk into this field.
We need something like the following (untested), unless you have a better idea:
I retro-fitted Clemens' patch to kernel 2.6.35 and tested it. There is a problem in card.c and endpoint.c in that KERN_WARN needs to be KERN_WARNING,
That's why I wrote "untested". :-)
but otherwise the patch works. I get this in dmesg:
ALSA sound/usb/endpoint.c:279: 2:1:1: unknown interface protocol 0xff, assuming v1 ALSA sound/usb/endpoint.c:439: 2:1:1: add audio endpoint 0x1 ALSA sound/usb/endpoint.c:279: 2:2:1: unknown interface protocol 0xff, assuming v1 ALSA sound/usb/endpoint.c:439: 2:2:1: add audio endpoint 0x81 ALSA sound/usb/endpoint.c:279: 2:2:2: unknown interface protocol 0xff, assuming v1 ALSA sound/usb/endpoint.c:439: 2:2:2: add audio endpoint 0x81 ALSA sound/usb/clock.c:243: current rate 48000 is different from the runtime rate 96000
It is still necessary to have the following bit of code in endpoint.c, otherwise sample rates of 44100 or 88200 do not work (the original problem).
The sample rate problems are handled by Felix' patch, which I applied yesterday.
All known FTU problem should now be fixed in the alsa-kernel tree.
Regards, Clemens