On Tue, 30 Aug 2022 10:08:51 +0200, chihhao chen wrote:
Hi Takashi,
I also think it should be a firmware problem but it happens with many different devices because of new set sampling rate behavior in k5.15.
Device 1 UAC1 [ 134.924359][T1000005] kworker/0:0: usb 1-1: [name:usbcore&]New USB device found, idVendor=04e8, idProduct=a04f, bcdDevice= 1.00 [ 134.925944][T1000005] kworker/0:0: usb 1-1: [name:usbcore&]New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 134.927338][T1000005] kworker/0:0: usb 1-1: [name:usbcore&]Product: Samsung USB C Earphone [ 134.928426][T1000005] kworker/0:0: usb 1-1: [name:usbcore&]Manufacturer: bestechnic [ 134.929432][T1000005] kworker/0:0: usb 1-1: [name:usbcore&]SerialNumber: 20160406.1
Does this show the same problem? If so, that's interesting because UAC1 has a completely different way of setting the sample rate.
Device 2 UAC3 [ 779.645324][T1003414] kworker/0:1: usb 1-1: [name:usbcore&]New USB device found, idVendor=05ac, idProduct=110a, bcdDevice=26.11 [ 779.647376][T1003414] kworker/0:1: usb 1-1: [name:usbcore&]New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 779.649492][T1003414] kworker/0:1: usb 1-1: [name:usbcore&]Product: USB-C to 3.5mm Headphone Jack Adapter [ 779.652262][T1003414] kworker/0:1: usb 1-1: [name:usbcore&]Manufacturer: Apple, Inc. [ 779.652273][T1003414] kworker/0:1: usb 1-1: [name:usbcore&]SerialNumber: DWH126301CLJKLTAF
Device 3 A XiaoMi adapter but it not in my hand now.
I will try to integrate k5.19 into my codebase.
At best, please give the alsa-info.sh output from each device. Run the script with --no-upload option and attach the output.
Then try to test whether the reported highest sample rate actually works as-is. That is, to see whether the problem is really about issuing the frequency change multiple times for different rates, or it's because issuing the highest rate screws up the device.
And, for UAC2/3 devices, it might be worth to try some known quirks, e.g. QUIRK_FLAG_VALIDATE_RATES, which was needed for MOTU (UAC2) devices. It's a bit 12 of quirk_flags option value.
Takashi
Thanks
On Tue, 2022-08-30 at 09:02 +0200, Takashi Iwai wrote:
On Tue, 30 Aug 2022 08:13:44 +0200, chihhao chen wrote:
Hi Takashi,
I tried the patch but this problem still happens.
I add some logs in snd_usb_init_sample_rate() in kernel-5.10 [ 146.260105][T1702328] writer: usb 1-1: [name:snd_usb_audio&]2:2 Set sample rate 96000, clock 0 protocol 0 [ 146.289892][T1002328] writer: usb 1-1: [name:snd_usb_audio&]2:2 Set sample rate 48000, clock 0 protocol 0
Because TinyAlsa tends to set highest rate for initialization and real rate for playback, it will still trigger two-times SAMPLING_FREQ_CONTROL USB requests.
Then this is a firmware problem of your device. The same problem would happen even with the old kernel if you run the application with different sample rates. Does the device work with 96kHz at all?
Could you give the lsusb -v output of the device, too?
Which kernel version should I try? kernel-5.19 or?
Yes, 5.19 should suffice.
Takashi