[pulseaudio-discuss] [PATCH] alsa-mixer: When setting hw volume, round always up with playback and always down with capture.

[Colin Guthrie]

'Twas brillig, and Colin Guthrie at 16/05/11 10:28 did gyre and gimble:
> 'Twas brillig, and David Henningsson at 16/05/11 07:23 did gyre and gimble:
>> On 2011-05-15 16:45, Tanu Kaskinen wrote:
>>> On Sun, 2011-05-15 at 17:43 +0300, Tanu Kaskinen wrote:
>>>> This was discussed on the mailing list:
>>>>
>>>> https://tango.0pointer.de/pipermail/pulseaudio-discuss/2011-May/010091.html
>>>>
>>>> ---
>>>>   src/modules/alsa/alsa-mixer.c |    2 +-
>>>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/src/modules/alsa/alsa-mixer.c
>>>> b/src/modules/alsa/alsa-mixer.c
>>>> index f236da0..8375a2f 100644
>>>> --- a/src/modules/alsa/alsa-mixer.c
>>>> +++ b/src/modules/alsa/alsa-mixer.c
>>>> @@ -893,7 +893,7 @@ static int element_set_volume(pa_alsa_element *e,
>>>> snd_mixer_t *m, const pa_chann
>>>>
>>>>           if (e->has_dB) {
>>>>               long value = to_alsa_dB(f);
>>>> -            int rounding = value>  0 ? -1 : +1;
>>>> +            int rounding = e->direction == PA_ALSA_DIRECTION_OUTPUT
>>>> ? +1 : -1;
>>>>
>>>>               if (e->volume_limit>= 0&&  value>  (e->max_dB * 100))
>>>>                   value = e->max_dB * 100;
>>>
>>> David, are you happy with this change, or does this require more
>>> discussion?
>>>
>>
>> I think it's OK. I think your theory is at least as good as mine, so
>> let's give it a try. For HDA Intel this does not make much of a
>> difference as Playback almost always only goes up to 0 dB whereas
>> Recording usually is above 0 dB (although not always).
> 
> Cool. I'll have to try this out in my tree with Source Output volumes as
> I'm having a brain freeze as to whether or not this is the right way
> round for what I observed. If it's not working I'll post back with some
> numbers.
> 
>> Might be worth adding a comment referring to the discussion behind the
>> reasoning though.
> 
> Yeah, I think a comment would be wise when this goes in.
> 
> I'll take care of it and report back sometime this week.

OK, here is the debug output from my run using this volume approach....

As you can see there are several points where the message:

"Written HW volume did not match with the request" is shown. This is
shown quite clearly when writing the volumes to h/w

I suspect this problem arrises due to the use of pa_cvolume_divide()
which is based around PA_VOLUME_NORM, when the second argument (the
software volume) is > PA_VOLUME_NORM.

Any thoughts on this are welcome.

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/]
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: volume-weirdness.txt
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20110516/23ecc634/attachment.txt>