On Sat, 24 Jul 2021 06:23:41 +0200,
<chihhao.chen@xxxxxxxxxxxx> wrote:
>
> From: "chihhao.chen" <chihhao.chen@xxxxxxxxxxxx>
>
> The following scenario describes an echo test for
> Samsung USBC Headset (AKG) with VID/PID (0x04e8/0xa051).
>
> We first start a capture stream(USB IN transfer) in 96Khz/24bit/1ch mode.
> In clock find source function, we get value 0x2 for clock selector
> and 0x1 for clock source.
>
> Kernel-4.14 behavior
> Since clock source is valid so clock selector was not set again.
> We pass through this function and start a playback stream(USB OUT transfer)
> in 48Khz/32bit/2ch mode. This time we get value 0x1 for clock selector
> and 0x1 for clock source. Finally clock id with this setting is 0x9.
>
> Kernel-5.10 behavior
> Clock selector was always set one more time even it is valid.
> When we start a playback stream, we will get 0x2 for clock selector
> and 0x1 for clock source. In this case clock id becomes 0xA.
> This is an incorrect clock source setting and results in severe noises.
> We see wrong data rate in USB IN transfer.
> (From 288 bytes/ms becomes 144 bytes/ms) It should keep in 288 bytes/ms.
>
> This earphone works fine on older kernel version load because
> this is a newly-added behavior.
>
> Signed-off-by: chihhao.chen <chihhao.chen@xxxxxxxxxxxx>
Thanks for the patch.
This looks like a regression introduced by the recent commit
d2e8f641257d ("ALSA: usb-audio: Explicitly set up the clock
selector"), which is a fix for certain devices. Too bad that the
behavior really depends on the device...
Maybe we need to introduce some flag to handle this commonly, but for
now, let's take the fix as is.
Takashi
