Hi Takashi,
It happens as follows on Android platform 1. When users want to play a sound, Android system will call pcm_open to get highest sample rate. In this function it uses ioctl : SNDRV_PCM_IOCTL_HW_PARAMS to collect information and triggers set-rate behavior. In this stage, system just initializes many audio parameters but not start to play yet. 2. Android system calls pcm_close 3. Android system calls pcm_open with suitable sample rate parameter and triggers set-rate again.
(pcm_open and pcm_close are functions in tinyalsa on Android.)
Users cannot not start and close immediately because Android system always auto-close stream if there is no sound for 3 seconds.
Yes I think this may be a timing issue. But it takes to much delay time to solve this phenomenon. I tested to add delay time and found 1. pcm_open to get highest sample rate 2. delay 150ms 3. pcm_close 4. pcm_open again This delay time results in severe playback latency.
Thanks
On Wed, 2022-08-31 at 10:04 +0200, Takashi Iwai wrote:
On Wed, 31 Aug 2022 09:03:03 +0200, chihhao chen wrote:
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.
Hm, but it's a USB-audio device, can't it just be plugged to a laptop...?
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.
I understand that part, but it's still weird. IIUC, it happens after closing the previous stream and start a new stream, right? Then can you play two different rates on 5.10 kernel; e.g. at first call snd_pcm_prepare with a high rate and stop/close immediately. Then start quickly the stream in a normal rate again. That should issue the sample rate changes in a similar way, and this should cause the same problem, if it's really about the call of endpoint / rate setups.
Or if it's more or less a timing issue, you might try to apply the delay quirk such as QUIRK_FLAG_CTL_MSG_DELAY_XXX or QUIRK_FLAG_IFACE_DELAY.
Takashi
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