[pulseaudio-discuss] [PATCH 4/4] alsa-mixer: Add force-hw-volume flag to alsa profile sets

[Colin Guthrie]

'Twas brillig, and David Henningsson at 16/05/11 07:43 did gyre and gimble:
> On 2011-05-15 16:02, Colin Guthrie wrote:
>> 'Twas brillig, and Jyri Sarha at 11/04/11 10:19 did gyre and gimble:
>>> On Sat, 09 Apr 2011 20:20:40 +0200, David Henningsson
>>> <david.henningsson at canonical.com>  wrote:
>>>> On 2011-04-08 17:18, Colin Guthrie wrote:
>>>>> 'Twas brillig, and oku at iki.fi at 08/04/11 15:18 did gyre and gimble:
>>>>>> From: Jyri Sarha<jyri.sarha at nokia.com>
>>>>>>
>>>>>> Before this patch, if any of the paths in a path set do not
>>>>>> support HW volume then the HW volume is disabled for the whole
>>>>>> set. In some cases this is a bit drastic measure. For instance,
>>>>>> if all but one of the paths support HW volume and dB there no
>>>>>> problem to pretend that we have HW volume for the whole set. The
>>>>>> path without any mixers to control will just always return 0 dB
>>>>>> and the rest is handled by SW volume. This patch adds a flag to
>>>>>> the mapping section of profile set file to enables this behavior.
>>>>>
>>>>> David, this sounds similar to your USB Headset issue from a couple
>>>>> days
>>>>> ago... or am I just reading too much into the description?
>>>>
>>>> Sort of - it just feels like neither of us has tried to do the right
>>>> thing so far - I added a workaround/quirk for a few devices, and this
>>>> patch adds a setting to turn something on and off.
>>>>
>>>> I'd like it to "just work".
>>>>
>>>> Or put in another way - what's the recommended default setting of this
>>>> new parameter, and why?
>>>>
>>>
>>> Target for my patch was to be non intrusive, but if you agree I can
>>> easily
>>>
>>> change my patch to always behave like force-hw-volume flag was set to
>>> true
>>> and remove the flag. It is even easier just to change the default for
>>> the
>>> flag.
>>
>> David, what's you're thinking on Jyri's suggestion here?
> 
> Not 100% sure on this one, what would be the reason why we would want
> the old behaviour?


Just bringing up this patch again as I'd like to knock this problem on
the head before v1.0.


Looking at the code that this affects, the force on flag was only run in
path_set_unify().


If I understand it correctly, if it finds a path set that cannot fully
support volume+dB, then it disables the volume+mute in all the paths in
that path set.

The problem arises from the fact that the same path can be used in
different path sets and thus if one path set contains an element that
busts things up, then we cripple every path set that uses it.

This logic, in itself is flawed, as it depends on the order that the
path sets are checked. If the paths and path sets are complex enough
with weird combos, the order of the path sets could affect whether a
given other path set works or not which is pretty messed up.


What I wonder is if we could add has_volume, has_dB and has_mute flags
to the path set itself. This allows us to shortcut straight to software
volume when dealing with the path sets, but doesn't cripple any given
path for use in other path sets.

This seems a cleaner approach than forcing the has_* flags on any given
path that shouldn't have it.



Also, with regards to mute, we only really need one of the paths to
support mute.... the fact that path_set_unify() disables mute support if
one path in the set does not it... but this is pretty bizarre as we only
really need to mute things once for it to be muted... it's not a
cumulative thing like volume. Seems a little backwards to me!


Anyway if this approach makes sense, let me know and I'll cook up a patch.

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/]