Hi Takashi, I will try to insall ALSA tools. I am testing these typec headsets on ARM8 smart phone platform. Because most x86 laptops support only 3.5mm input, I cannot test these typec devices. This problem should have something to do with host. If I remove configure_endpoints() in snd_usb_hw_params() like k5.10 behavior, this problem does not happen. It seems that to set frequency multiple times leads to headset abnormal phenomenon. Thanks On Wed, 2022-08-31 at 07:18 +0200, Takashi Iwai wrote: > 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
