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. Which kernel version should I try? kernel-5.19 or? Thanks On Tue, 2022-08-30 at 07:54 +0200, Takashi Iwai wrote: > On Mon, 29 Aug 2022 20:15:33 +0200, > Takashi Iwai wrote: > > > > On Mon, 29 Aug 2022 14:16:27 +0200, > > Takashi Iwai wrote: > > > > > > On Mon, 29 Aug 2022 10:50:58 +0200, > > > chihhao chen wrote: > > > > > > > > Hi Takashi, > > > > > > > > Yes. > > > > > > > > To issue SAMPLING_FREQ_CONTROL USB request two times is root > > > > cause of > > > > this issue. > > > > > > Hm, is it a UAC1 device? Such a device should work with multiple > > > SAMPLING_FREQ_CONTROL invocations, but some device might be not > > > tolerant or buggy... The multiple init_sample_rate() invocations > > > may > > > happen with the older kernel under certain situations, so maybe > > > we > > > need a different fix. > > > > > > How about the patch like below? > > > > It's missing the clearance for suspend/resume. > > The revised patch is below. > > ... and after reading the mail again, I noticed that it's all > rubbish, scratch the previous ones. > > Have you tested it with the later kernel? I guess this has been > already addressed. In the recent kernel, the rate is set per > assigned > clock, hence it won't be set up twice unnecessarily. > > > Takashi
