[pulseaudio-discuss] [BUG?] I get a profile with 2 outputs, but if I mute headphone it mutes both ports

[Tanu Kaskinen]

On Thu, 2015-11-05 at 09:04 +0100, David Henningsson wrote:
> 
> On 2015-11-04 12:09, Tanu Kaskinen wrote:
> > On Mon, 2015-11-02 at 09:36 +0100, David Henningsson wrote:
> > > 
> > > On 2015-11-01 13:41, Tanu Kaskinen wrote:
> > > > On Sat, 2015-10-31 at 17:37 +0100, GMAIL wrote:
> > > > > 
> > > > > Le 31/10/2015 12:19, Tanu Kaskinen a écrit :
> > > > > 
> > > > > > I suspect that the "Front" volume and mute elements can be used to
> > > > > > control the line out without affecting the headphones. The problem is
> > > > > > that PulseAudio's alsa configuration assumes that the "Front" element
> > > > > > affects both line out and headphones (there's a comment saying that "on
> > > > > > some machines Front is actually a part of the Headphone path").
> > > > > > 
> > > > > > /usr/share/pulseaudio/alsa-mixer/paths/analog-output-headphones.conf
> > > > > > contains this:
> > > > > > 
> > > > > >         [Element Front]
> > > > > >         switch = mute
> > > > > >         volume = zero
> > > > > > 
> > > > > > If you change that to
> > > > > > 
> > > > > >         [Element Front]
> > > > > >         switch = off
> > > > > >         volume = off
> > > > > > 
> > > > > > does that fix the problem for you?
> > > > > > 
> > > > > Indeed this fixes my problem, thanks!
> > > > > 
> > > > > I'm a bit confused by the comment in the .conf file though. So, despite
> > > > > PA detecting the rear line out port exactly as it states, this "Element
> > > > > Front" is actually part of the headphones "paths"? that is rear line out
> > > > > is considered as part of "Element Front"?
> > > > I'm not sure what you mean with your last question. The rear line out
> > > > isn't a "part" of the "Front" mixer element, it's the other way around.
> > > > You have two paths, headphones and line out. PulseAudio considers the
> > > > "Front" mixer element to be part of both paths, even though on your
> > > > machine it's only a part of the line out path.
> > > > 
> > > > I'm not sure if we can fix this upstream. To me it would seem logical
> > > > for the kernel to promise that "Front" only refers to line out, and if
> > > > on some machine it also affects the headphone path, then that should be
> > > > considered a kernel bug, and the kernel should rename the element.
> > > > David, what do you think?
> > > 
> > > Well, technically what comes out of a headphone are front left and front
> > > right channels, so to some degree it makes sense that "Front" should be
> > > a part of the headphone path.
> > 
> > Sure, "Front" could be defined to affect both line out and headphone
> > paths. The problem is that currently it seems to mean "line out only"
> > on some machines and "line out and headphones" on other machines. If
> > "Front" is defined to affect both paths, then we need some other name
> > for controls that only affect the line out path.
> 
> I believe the logical name for such a control would be "Line Out Front". 
> (Which we currently do not support in the line out path, btw, and I 
> haven't seen it in the wild, either.)

I suppose the kernel is usually able to automute line out when
headphones are plugged in? If so, then why doesn't the kernel expose
the mute control to the userspace?

> > > But there's another thing behind this. 1458:a002 is a problematic one.
> > > Gigabyte uses that SSID for several different motherboard, and some of
> > > them have broken front headphone detection (or we don't know how to turn
> > > it on correctly), so we've turned it off by default for all 1458:a002.
> > > That's why you don't get port switching by default, and probably also
> > > why the kernel does not automute for you, like it does on most other
> > > motherboards which have the same codec configuration.
> > 
> > I'm not sure that's relevant for dealing with the "Front" element.
> > Maybe you mean that the kernel doesn't know what paths "Front" affects?
> > In that case, the kernel could name the control "Gigabyte Front" so
> > that the userspace knows too that it's not known what the control does.
> 
> Well, in other cases where kernel does automute automatically, you will 
> never get output from both line out and headphones. And that was part of 
> the original problem, I believe?

Yes, probably the original reporter would be happy with just kernel-
side automuting.

-- 
Tanu