Re: missing sound on kernel-5.15

[chihhao chen <chihhao.chen@mediatek.com>]

Hi Takashi,

Yes no error reported and data on USB bus is also complete. (Use USB
analyzer to collect packets on bus and check these data.)

I added delay right after find_substream_format() in
snd_usb_hw_params() as follows
1. first time call snd_usb_hw_params(), do nothing
2. second time call snd_usb_hw_params(), delay 150ms after
find_substream_format()

I tried to set snd_usb_use_vmalloc false but this problem still
happened.

Thanks


On Wed, 2022-08-31 at 12:48 +0200, Takashi Iwai wrote:
> On Wed, 31 Aug 2022 11:26:44 +0200,
> chihhao chen wrote:
> > 
> > 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.
> 
> OK, and it's only about the missing sound, and no error is reported
> from the system itself, right?  And at which code path did you put
> the
> delay of 150ms?
> 
> Also, as a blind shot, what if you use the coherency buffer by
> passing
> vmalloc=0 option to snd-usb-audio module?
> 
> 
> Takashi
> 
> > 
> > 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