[pulseaudio-discuss] [RFC] Should we set Front=0dB for the headphone path?

David Henningsson david.henningsson at canonical.com
Wed Aug 31 05:16:33 PDT 2011

On 08/31/2011 11:40 AM, Colin Guthrie wrote:
> 'Twas brillig, and David Henningsson at 31/08/11 10:05 did gyre and gimble:
>> On 07/04/2011 10:19 AM, David Henningsson wrote:
>>> On 2011-07-03 15:00, Colin Guthrie wrote:
>>>> 'Twas brillig, and David Henningsson at 01/07/11 14:03 did gyre and
>>>> gimble:
>>>>> I wonder if we're better off with the attached patch. I've seen more
>>>>> than one system where the volume control named "Front" is a part of
>>>>> audio path for headphones. The attached patch would be somewhat of a
>>>>> compromise: While we don't merge it into the path, as that would be
>>>>> regressing machines where "Front" isn't a part of the audio path, it
>>>>> would still enable sound on these machines. The question is if "Front"
>>>>> is turning on some output it shouldn't on some machines, but I think it
>>>>> wouldn't: this should (for all common systems I can think of) be fixed
>>>>> through the driver's auto-mute anyway.
>>>> Seems like a reasonable compromise to me, but does anyone else have any
>>>> opinions on this? Or perhaps any cases where regressions could be
>>>> caused?
>>>> (see my latest comment on the path_set_condense() method which checks
>>>> volume use for OFF which could actually get in the way here!!)
>>>>> The other option would be to quirk every single machine that has this
>>>>> problem to a separate udev rule ->  profile-set ->  path .conf file.
>>>>> What do you think?
>>>> Yeah I really don't like that option. If we do need some quirks here I'd
>>>> much rather see them implemented in a more fine grained way than with
>>>> udev rules... as it's a bit of blunt object. But ideally avoid it
>>>> altogether.
>>>> Col
>>> Ok, here's a patch properly formatted for inclusion.
>> After having seen yet another with the same problem, I have now included
>> this patch in Ubuntu.
> I presume you don't mean the latter option (udev quirks)?
> If it's the first one, we should probably carry it upstream until a
> better solution is available. I'd rather do it once in a blessed way
> (even if it's a work around) than having different quirks in different
> distros if possible (makes generic upstream support easier).

Yes, I recommend applying the previously submitted patch [1] in 
PulseAudio upstream, sorry if that was unclear.

[1] See 

David Henningsson, Canonical Ltd.

More information about the pulseaudio-discuss mailing list