On Wed, 31 Aug 2022 05:39:56 +0200, chihhao chen wrote:
Hi Takashi,
Yes they all show the same phenomenon : missing first sound randomly when users start playback.
Ah, that's what I misunderstood: I thought the output were completely missing.
I tried to run alsa-info.sh but got "This script requires amixer utility to continue" message.
Too bad. Any chance to install those standard ALSA tools?
For Samsung USB C Earphone UAC1 device, I tested not to set 96000(highest rate) but 48000 twice and this issue still happened.(Original behavior : set 96000 then set 48000 -> Try to set 48000 then set 48000 instead) So I think the problem might be related to setting frequency multiple times.
For Apple USB-C to 3.5mm Headphone Jack Adapter UAC3 device, I confirmed its badd_profile is UAC3_FUNCTION_SUBCLASS_HEADPHONE so it will not go into QUIRK_FLAG_VALIDATE_RATES quirk function. Besides its initialization sequence in k5.15 is to set 48000 twice and because this rate works well in k5.10, do I still need to set lower rate to test?
In that case, better to test a few other options.
But before going in that way, let's check whether the problem depends on the host or not. Which host are you testing? An ARM system? Does the problem happen with the same USB-audio device on another machine (e.g. x86 laptop)?
Takashi
Thanks
On Tue, 2022-08-30 at 10:24 +0200, Takashi Iwai wrote:
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