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

[Colin Guthrie]

'Twas brillig, and David Henningsson at 31/08/11 14:16 did gyre and gimble:
> 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
> http://lists.freedesktop.org/archives/pulseaudio-discuss/2011-July/010521.html

OK, In my tree now.

Thanks!

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]