missing sound on kernel-5.15

[chihhao chen]

Hi Takashi,

Yes they all show the same phenomenon : missing first sound randomly
when users start playback.

I tried to run alsa-info.sh but got "This script requires amixer
utility to continue" message.

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?

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