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

[David Henningsson]

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.)

>> 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?


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic