From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B0223C4338F for ; Sat, 24 Jul 2021 08:04:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8A98060E96 for ; Sat, 24 Jul 2021 08:04:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234587AbhGXHXf (ORCPT ); Sat, 24 Jul 2021 03:23:35 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:38100 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234216AbhGXHXe (ORCPT ); Sat, 24 Jul 2021 03:23:34 -0400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 4EC3C2001B; Sat, 24 Jul 2021 08:04:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1627113845; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=24IQqn9FXptEdDFM0uvk5v9JwwGmH7qRb69eCI8SxgI=; b=WtQlljWjRL/CjVz5fyWTfQVwmwpsKvkz5L4ASWaikYX97ZKg9d2H9t9A6niDUDT/6phiGX 1QnQFlfkVrbLO/lnWUJ+rr2PtEvXp7vCmLwxtefqkeQMvLe6dKWbqV2hCD1HeZKa/zY6aH 2HBBR/LFn6C8ei+9Wir1HgfOGxCvan4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1627113845; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=24IQqn9FXptEdDFM0uvk5v9JwwGmH7qRb69eCI8SxgI=; b=MTkc/JF87R3cvXo51USXV8O+c1pl2c2NBub8Ce5QknywyBUKrf/C/fNIuDeWTQ6iCeXOlS URW7hRR0YVOkFzAg== Received: from alsa1.suse.de (alsa1.suse.de [10.160.4.42]) by relay2.suse.de (Postfix) with ESMTP id 1A5A0A3B87; Sat, 24 Jul 2021 08:04:05 +0000 (UTC) Date: Sat, 24 Jul 2021 10:04:05 +0200 Message-ID: From: Takashi Iwai To: Cc: , , , , , , , , Subject: Re: [PATCH] ALSA: usb-audio: fix incorrect clock source setting In-Reply-To: <1627100621-19225-1-git-send-email-chihhao.chen@mediatek.com> References: <1627100621-19225-1-git-send-email-chihhao.chen@mediatek.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 24 Jul 2021 06:23:41 +0200, wrote: > > From: "chihhao.chen" > > 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 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