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 alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 295F9C282DE for ; Thu, 13 Mar 2025 08:35:52 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [45.14.194.44]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 7AF4E60355; Thu, 13 Mar 2025 09:35:40 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 7AF4E60355 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1741854950; bh=svCHiIU35FWLeQw6W3i0ZjFjq2K4FovNbEzLOeMtloI=; h=From:To:In-Reply-To:References:Subject:Date:List-Id:List-Archive: List-Help:List-Owner:List-Post:List-Subscribe:List-Unsubscribe: From; b=RVLeeZid6Rpkn+UOLIbpLK8rD/XaDJGRjUWO3d1ZlbL6WEKxrj7BnCSp66J8SYkN1 fN9ErAD5PmEFIDuAdZ4rvOyDR/2hVjPz6vpBgIaV3zKbcHQBhE7gicKEAy2Evp/ZHi /lBCxRv/kZzzdTZsWHTrl3zVL8VMX0OH62j4s7nE= Received: by alsa1.perex.cz (Postfix, from userid 50401) id 04FB2F8057A; Thu, 13 Mar 2025 09:35:11 +0100 (CET) Received: from mailman-core.alsa-project.org (mailman-core.alsa-project.org [10.254.200.10]) by alsa1.perex.cz (Postfix) with ESMTP id 60046F8052E; Thu, 13 Mar 2025 09:35:11 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 9BECDF8026D; Thu, 13 Mar 2025 09:34:33 +0100 (CET) Received: from webhooks-bot.alsa-project.org (vmi2259423.contaboserver.net [45.14.194.44]) by alsa1.perex.cz (Postfix) with ESMTP id 95F3DF80095 for ; Thu, 13 Mar 2025 09:34:31 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 95F3DF80095 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: GitHub issues - opened To: alsa-devel@alsa-project.org Message-Id: <182c4fc6c4274600-webhooks-bot@alsa-project.org> In-Reply-To: <182c4fc6c3010c00-webhooks-bot@alsa-project.org> References: <182c4fc6c3010c00-webhooks-bot@alsa-project.org> Subject: Dynamic PCM switching in ALSA with multi room audio sync support Date: Thu, 13 Mar 2025 09:34:33 +0100 (CET) Message-ID-Hash: LTIKKB5RO527XB5H4OBISCJ4TQXW2U3T X-Message-ID-Hash: LTIKKB5RO527XB5H4OBISCJ4TQXW2U3T X-MailFrom: github@alsa-project.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-alsa-devel.alsa-project.org-0; header-match-alsa-devel.alsa-project.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: alsa-project/alsa-lib issue #443 was opened from Asikbct: **Challenges:** The PCM device is already opened by applications, making it difficult to switch to a new output seamlessly. Since most Music Service SDKs initialize the PCM device at startup, re-initializing it would require users to manually reopen their streaming app and re-select the device, negatively impacting the user experience. **Requirement:** User can switch between different audio output options (Line Out, Optical, USB Out, Bluetooth, etc.) at any time. The transition to a new output should be seamless, whether the user is currently playing a song from any music sources. Playback should resume on the newly selected output without requiring the user to manually reopen the content provider app and restart playback from the beginning. **Problems:** 1. **Reopening the PCM** Most music services open and configure the PCM device during initialization. Changing the PCM device (e.g., switching from Line Out to Optical Out) requires reopening it, which forces music services to reinitialize. This may require the end user to relaunch the respective app, reselect the device, and restart playback, impacting the user experience. 2. **Multiroom Sync** Many music services that support multiroom synchronization rely on Linux ALSA APIs like snd_pcm_delay() to estimate the kernel buffer fill level and synchronize audio playback across devices. Any new approach to meet the requirements, should not disrupt this synchronization. I've tried virtual loopback, PulseAudio, and a customized dswitch plugin. While all these methods enable dynamic PCM switching, I couldn't achieve stable long-term latency on the same PCM. Any guidance or suggestions on achieving stable long-term latency along with dynamic PCM switching would be greatly appreciated. Issue URL : https://github.com/alsa-project/alsa-lib/issues/443 Repository URL: https://github.com/alsa-project/alsa-lib