From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tanu Kaskinen Subject: Re: [PATCH] conf: HdmiLpeAudio: remove the "front" pcm definition Date: Thu, 05 Oct 2017 18:10:11 +0300 Message-ID: <1507216211.3224.5.camel@iki.fi> References: <20171004194400.14401-1-tanuk@iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by alsa0.perex.cz (Postfix) with ESMTP id E61C4266A73 for ; Thu, 5 Oct 2017 17:10:19 +0200 (CEST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Takashi Iwai Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org On Thu, 2017-10-05 at 08:38 +0200, Takashi Iwai wrote: > On Wed, 04 Oct 2017 21:44:00 +0200, > Tanu Kaskinen wrote: > > > > PulseAudio assumes that the "front" pcm device always refers to an > > analog device, not HDMI. While that assumption is not really valid, the > > reality is that without that assumption PulseAudio can't know whether > > "front" and "hdmi" refer to a different or the same device. > > > > The HDMI LPE driver doesn't allow audio streaming while the HDMI cable > > is unplugged, so PulseAudio has to know when it's plugged in and when > > it's not. If both "front" and "hdmi" devices exist, PulseAudio will > > notice that HDMI is unplugged, but it doesn't know that "front" refers > > to the same device, and PulseAudio will try to use the "front" device > > with bad consequences. The kernel driver's refusal to stream any audio > > makes PulseAudio enter an infinite loop and then the kernel kills > > PulseAudio, because it consumes too much CPU time in a realtime thread. > > > > While the looping in PulseAudio could probably be fixed, that wouldn't > > change the fact that PulseAudio thinks that there is an analog device. I > > believe it's best to avoid having the same device as both "front" and > > "hdmi" in alsa-lib. > > > > I removed also the surround configuration includes. I don't think they > > had any effect anyway, so I wonder why they were there in the first > > place. > > These definitions are there for LPCM surround channels. Are they supposed to do something useful? When PulseAudio probes the surround40:0 device, opening the device fails: alsa-util.c: Trying surround40:0 with SND_PCM_NO_AUTO_FORMAT ... (alsa-lib)confmisc.c: Unable to find definition 'cards.HdmiLpeAudio.pcm.surround40.0:CARD=0' (alsa-lib)conf.c: function snd_func_refer returned error: No such file or directory (alsa-lib)conf.c: Evaluate error: No such file or directory (alsa-lib)pcm.c: Unknown PCM surround40:0 > The biggest problem behind the scene is that we mixed up both logical > and physical configurations. The "front" or "surround51" belong to > the former, while "hdmi" belongs to the latter. > > In the past, there was only SPDIF that has only two stereo channels, > so the logical configuration was fixed with that. We copied that > config for HDMI/DP, and now we hit the inconsistency more clearly... > > I suppose the PA issue gets fixed just by this removal? If yes, I'm > willing to apply it, including in the next release. A user reported that removing the "front" definition fixes the PA issue, together with jack detection patches for PA that haven't been merged yet. -- Tanu https://www.patreon.com/tanuk