[pulseaudio-discuss] [PATCH] alsa: don't assume that hw:x is an analog output

[Takashi Iwai]

On Sat, 29 Apr 2017 19:00:28 +0200,
Tanu Kaskinen wrote:
> 
> On Sat, 2017-04-29 at 17:42 +0200, Takashi Iwai wrote:
> > On Sat, 29 Apr 2017 14:45:41 +0200,
> > Arun Raghavan wrote:
> > > 
> > > (looping in Takashi for his thoughts, since we'd discussed this a long
> > > time ago)
> > > 
> > > On Fri, 28 Apr 2017, at 12:38 AM, Tanu Kaskinen wrote:
> > > > On Wed, 2017-04-26 at 14:19 +0530, Arun Raghavan wrote:
> > > > > On Mon, 24 Apr 2017, at 08:36 PM, Tanu Kaskinen wrote:
> > > > > > Previously, if front:x didn't work, we would try to use hw:x for analog
> > > > > > stereo output. There's no guarantee that hw:x is an analog output,
> > > > > > however. For example, the Intel HDMI LPE driver uses hw:x for HDMI
> > > > > > output, and PulseAudio incorrectly created analog profiles for that
> > > > > > card, because front:x doesn't work but hw:x does.
> > > > > > 
> > > > > > This patch changes things so that the analog stereo mapping doesn't any
> > > > > > more use hw:x as a fallback. A separate "unknown stereo" fallback
> > > > > > mapping is added to handle the rare case where hw:x is the only PCM
> > > > > > device that works.
> > > > > > 
> > > > > > BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=100488
> > > > > > ---
> > > > > 
> > > > > I recall that front: actually adds a softvol on top of hw: (in some
> > > > > cases?), and we actually wanted to move to hw: always.
> > > > 
> > > > Using hw: always seems like a bad idea (for the reasons described in
> > > > this patch).
> > > > 
> > > > > Do we know if that's still true?
> > > > 
> > > > At least I don't know.
> > 
> > The softvol is skipped by passing SND_PCM_NO_SOFTVOL bit flag at
> > opening a stream even if softvol is included in the configuration.
> > IIRC, this was introduced exactly for PA :)
> 
> I looked at some old discussions[1][2] to find out why we're still not
> using the NO_SOFTVOL flag. The problem seems to be that using the flag
> isn't enough to guarantee that there aren't any softvol elements in the
> mixer. It seems that if any program ever has used "front:" without the
> NO_SOFTVOL flag, the softvol PCM element will be created and will
> remain forever on that system. If the mixer element has been created
> once, then starting to use NO_SOFTVOL causes a regression, because
> PulseAudio will see and use the PCM mixer element, but the mixer
> element won't be hooked to the actual softvol plugin. That is, the
> mixer element won't have any effect on the volume.
> 
> In [1] Takashi says that PulseAudio can check if the PCM element is
> user-created, but in [2] Jaroslav says that it's not possible.

It is still possible to differentiate: the "PCM" volume is with
SND_CTL_ELEM_ACCESS_USER in its access bits when created by softvol,
while the one from the kernel driver is without that.

I guess the issue Jaroslav mentioned is that you cannot judge in 100%
whether it is from the softvol.  It might be that user created for a
different purpose.

But, in either ways, PA doesn't want to care about such a volume
element, so it'd be safe to say that as default PA should skip the
user-element.

The only useful case to allow user-element would be to deal with the
faked card, e.g. via aloop and pass-through all ctls via user ctls.
But such a card won't be detected properly by PA in anyway.  So,
although it'd be still required to allow the user-space elements, it
may be optional, e.g. enabled only by some options.


Takashi

> I didn't see anyone suggesting using "hw:" instead of "front:", and I
> don't see how that would help anyway. Arun, do you think this patch is
> ok to be applied?
> 
> [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2010-August/031184.html
> [2] https://lists.freedesktop.org/archives/pulseaudio-discuss/2013-May/017313.html
> 
> -- 
> Tanu
> 
> https://www.patreon.com/tanuk
>