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 3F271C54EE9 for ; Tue, 20 Sep 2022 06:50:48 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 02ABC3E8; Tue, 20 Sep 2022 08:49:56 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 02ABC3E8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1663656646; bh=Afe0DyZ1laxADHWVYu835eHJMlx9cQz8u0so3pJs7GM=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=EjHJ19C3kKHU0qck2wZ/3CACk1XkNHoCPLDFFlSzVLsLACZzsG50pVKbCwoa3+nBV Sf77DczGDVM6mMb0SXwJszFcG+sHbpXIY/M8m0z4LKg0IUucJwA0F9DCFlCd+XBP/e nB4dQi06D63LBIg/JoqHI/YUfu5Gd/JZ5TjK0EnQ= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 5D545F80153; Tue, 20 Sep 2022 08:49:55 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id B3D84F80155; Tue, 20 Sep 2022 08:49:53 +0200 (CEST) Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 3BD01F8012B for ; Tue, 20 Sep 2022 08:49:49 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 3BD01F8012B Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="PfNdz4ya"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="IeMLZkCo" 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-out2.suse.de (Postfix) with ESMTPS id 200C01F8C3; Tue, 20 Sep 2022 06:49:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1663656589; 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=uj9QyS37xblxQQ7D224sB0R7y5DwoAJPp1T1nsVtzJQ=; b=PfNdz4yamV/Y20czacZ0byUh8x5VKmXGBRQ4ttjzD6jaltZO/O4Yc9aIw0dMnkY/uaVzOT xHYsRefcxMAnO2pLwSwRiFHxv9efGO4jReVq2CBWX3+iGdcIqpFcCaFAVKG7MF+gkGmqfF qJvkE5cwUX2oUHXmvvhSjjYbIdYEFaQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1663656589; 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=uj9QyS37xblxQQ7D224sB0R7y5DwoAJPp1T1nsVtzJQ=; b=IeMLZkCofWsinPBK6FtZ5Tel5twOoI43GBpF6YaJPChWcAs/o5tqHB4c4vJ8sp3IQMoEfq 21y3fQ9DXPplWACA== 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 EFF2E1346B; Tue, 20 Sep 2022 06:49:48 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id +pArOYxiKWPvOAAAMHmgww (envelope-from ); Tue, 20 Sep 2022 06:49:48 +0000 Date: Tue, 20 Sep 2022 08:49:48 +0200 Message-ID: <87illih75f.wl-tiwai@suse.de> From: Takashi Iwai To: Kai Vehmanen Subject: Re: HDA HDMI PCM device allocation In-Reply-To: References: <2f37e0b2-1e82-8c0b-2bbd-1e5038d6ecc6@perex.cz> 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 Cc: ALSA development X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" Jaroslav, thanks for bringing the issue. I follow up onto Kai's reply. On Mon, 19 Sep 2022 19:43:28 +0200, Kai Vehmanen wrote: > > Hi, > > On Mon, 19 Sep 2022, Jaroslav Kysela wrote: > > > We have two methods to map the PINs in the HDA HDMI driver to the PCM devices > > (legacy/static - 1:1 mapping, dynamic - used for new devices with the MST > > capability). There is also set of converters in each HDMI codec and the number > > of simultaneously used PCM devices cannot go beyond this count of converters > > in hardware (otherwise -EBUSY error is returned). The count of converters is 3 > > or 4 depending on the hardware. > > roughly yes. There is some further details and variation in implementation > the dynamic method if you look at patch_hdmi.c:generic_hdmi_build_pcms(). > E.g. recently we added 'dyn_pcm_no_legacy' to start limiting the amount of > PCM nodes created. But yeah, this is exactly to move to the direction you > are proposing. > > > Things to discuss: > > > > It seems quite straight to limit the count of created PCMs to the count of > > converters. We cannot use more anyway and it does not help, if more PCM > > devices are allocated (and Jacks reported) to applications when they cannot be > > used simultaneously. > > 5~Agreed. When the amount of HDA pins (~= possible physical ports) was > small, and before DP-MST (or when DP-MST was available only on a small > subset of physical ports), there was clear value in having sticky > PIN-to-PCMx mapping. If you plugged a monitor to certain HDMI or DP port, > it would show up in the same PCM node. If you had a DP-MST hub, the > monitor/receivers behind the hub, would also end up mapped to the > familiar ALSA PCM nodes. > > But especially with USB-C, the # of possible topologies has shot up > (basicly any port can host a DP-MST hub), making this approach less and > less practical. > > With SOF, we had further constraints in integrating with ASoC, so we've > basicly limited PCM (FE) nodes to number of converters (PCM BEs) from the > start. Now with dyn_pcm_no_legacy, this starts to be used also with > non-DSP usage via snd-hda-intel (with Intel Tiger Lake and newer). At > least so far we've not got any negative feedback on this, so road seems > clear to move ahead with this approach. There is certainly a lot of cruft > in the code to maintain all the legacy options. Yes, and I thought this flag should suffice and provide the dynamic assignment feature, if it's set to every new model in future as default (at least about the converters)? > > There is a corner case, when more HDMI devices are connected than the count of > > converters. In this case, an extra method (a module parameter and/or a control > > element and/or procfs) may be used to filter unwanted HDMI devices. It may be > > At least on Intel platforms this is not a problem. The number of > converters is aligned with number of display pipes. So you'll never have > more HDMI devices connected than the max number of converters. I guess it's true in general that a converter corresponds to an output for all graphics implementations, so far. Of course, it's not set on stone, so things may change. But I'm afraid that it'll be beyond the HD-audio codec itself. > > Impact to applications: > > > > Those days, pulseaudio or pipewire servers are mostly used on the current > > hardware. Both servers share the legacy probe code for HDMI devices - they are > > trying to open PCM devices sequentially and check for the error code. There > 5~> should not be a problem when the connected HDMI devices do not go > beyond the > > count of converters. A minor issue is that the name of the used sink/port may > > be different (users may be forced to reselect the output path). > > > > For other applications, the PCM device assigned to the connected HDMI device > > may be different (available in a different ALSA device name). I do not think > > that it's a big issue. It should be easy solvable with an updated software > > configuration. > > Ack, and this model is already required for smooth integration. With > snd-hda-intel, while PCM routing tries to maintain legacy PCM mapping, it > cannot be guaranteed in all possible cases. On systems using SOF, there's > no legacy mapping at all. > > So the right (and robust) approach for apps to select the PCM for > HDMI/DP audio is to use: > - UCM tells which kcontrol to monitor for jack event > - JackControl "HDMI/DP,pcm=3 Jack" > - Jack control tells whether receiver is connected or not > - "numid=22,iface=CARD,name='HDMI/DP,pcm=3 Jack'" > - the ELD data describes receiver properties > - "numid=27,iface=PCM,name='ELD',device=3" > > The above is done by Pulseaudio when UCM is used (and followed by > Pipewire) and CRAS on ChromeOS. The above can give user sensible GUI > information on where to route the audio, and provide enough tools for > applications to provide persistancy (audio is routed to Foobar XYZ monitor > always, indepedently of the order in which the display/receivers are > discovered). > > In simple setups (one HDMI/DP receiver with audio capability connected), > the receiver is always connected to the first HDMI/DP PCM of the card. Sounds reasonable to me. thanks, Takashi