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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 59BA0ECAAD5 for ; Mon, 5 Sep 2022 12:42:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238202AbiIEMmr (ORCPT ); Mon, 5 Sep 2022 08:42:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33440 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238198AbiIEMmc (ORCPT ); Mon, 5 Sep 2022 08:42:32 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 223E04D4FE; Mon, 5 Sep 2022 05:37:48 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id C2B7A38888; Mon, 5 Sep 2022 12:37:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1662381466; 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=2eMqoGYrzYEdYINttm3RJ00lrnnIdSpt5LJvWHgsFVA=; b=cU3PlLNTcEA2Y7jMqYZFdRS7rpJ0FoqXU9r8khq4fduj18SsR2+zJLglYeL4XvrbJFsjLC LF90rfbhjq5bEDJPX9gVE6DF7Pi6UJIBymQJDSQp9p47Tqht+ObhXjhguGHI/UplRBJtGU V3k9q5ttRuJVCqR5sixhZRjRQUqOOwU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1662381466; 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=2eMqoGYrzYEdYINttm3RJ00lrnnIdSpt5LJvWHgsFVA=; b=cfWe+5ViDL+WuUhyGi427MF67M65tBZPJ12taKUoNcAtED2h+nFABP40BIO4wecfF/fHKO 57lFpBRD2iKx9rCQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 9C26F13A66; Mon, 5 Sep 2022 12:37:46 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id h6F0JZrtFWPvBwAAMHmgww (envelope-from ); Mon, 05 Sep 2022 12:37:46 +0000 Date: Mon, 05 Sep 2022 14:37:46 +0200 Message-ID: <87r10qj8th.wl-tiwai@suse.de> From: Takashi Iwai To: "Jason A. Donenfeld" Cc: alsa-devel@alsa-project.org, LKML , stable , =?ISO-8859-4?Q?Nikl=E0vs_Ko=B6es=F1ikovs?= <89q1r14hd@relay.firefox.com>, Wim Taymans Subject: Re: [PATCH] ALSA: usb-audio: Don't refcount multiple accesses on the single clock In-Reply-To: References: <20220905101403.1435037-1-Jason@zx2c4.com> <87sfl6jbb3.wl-tiwai@suse.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Mon, 05 Sep 2022 14:06:45 +0200, Jason A. Donenfeld wrote: > > On Mon, Sep 5, 2022 at 1:44 PM Takashi Iwai wrote: > > > > On Mon, 05 Sep 2022 12:14:03 +0200, > > Jason A. Donenfeld wrote: > > > > > > This reverts commit 03a8b0df757f1beb21ba1626e23ca7412e48b525. > > > This reverts commit c11117b634f4f832c4420d3cf41c44227f140ce1. > > > > > > Pipewire and PulseAudio start devices with 44.1khz before changing them > > > to 48khz (or something different). By locking the rate, daemons are > > > unable to enumerate possible rates, and so they never change them to a > > > more optimal rate. This revert patch should allow 48khz audio again. > > > > Well, in that case, the revert is no right solution, IMO. > > If the patch caused a problem, it means that the application tries to > > change the rate while it's being still running by another. If it > > worked, it worked just casually without noticing the bad behavior. > > Not sure this is really what's happening. I think the issue is that > alsa reports that the device only supports a limited set of rates. This patch doesn't change the "report" mechanism. Instead what this patch does is to bail out as an error if you try to change the rate of a coupled stream while another stream is already running. > Pipewire then doesn't see 48khz, so it doesn't try to > stop,reclock,start. > > Maybe Wim or Niklavs can provide more info about this. More information is appreciated :) Takashi