[alsa-devel] wrong decibel data?

[Colin Guthrie]

'Twas brillig, and Raymond Yau at 28/06/10 02:47 did gyre and gimble:
> 2010/6/23 Colin Guthrie <gmane at colin.guthr.ie>
>> I can't speak for him with regards to the full setup of the mixer path
>> probing stuff, so perhaps "front" should be edited out of this for
>> paths. It would likely be a fairly trivial change to configuration files
>> rather than any code changes.
>>
>>
> Well , He had already hardcoded to use "hw:card_number" in dbverify.c , it
> is only PA server still try to open mixer device "front"

Yeah dbverify is a very simple tool that doesn't really warrant an
advanced interface. There may be other reasons to use hw: directly too.


> The tooltip of gnome volume control in Fedora 13 clearly indiacte that 100%
> is 0dB for intel8x0 which use ac97 codec  when you put the cursor on top of
> the speaker icon at the system bar
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=618551
> 
> according to gnome-media-developer  Bastien Nocera
> 
> In any case, we only display what PulseAudio tells us, so you should poke the
> PulseAudio devs about this.
> 
> This is the code in question:
> gdouble
> gvc_mixer_stream_get_decibel (GvcMixerStream *stream)
> {
>         g_return_val_if_fail (GVC_IS_MIXER_STREAM (stream), 0);
> 
>         return pa_sw_volume_to_dB(
>                         (pa_volume_t)
> gvc_channel_map_get_volume(stream->priv->channel_map)[VOLUME]);
> }
> 
> 
> 
> if you don't have any ac97 sound card , you can user virtualbox which has an
> emulated intel8x0 sound card

Dude, we've talked about this already. The PA server applies no software
amplification and has set the controls provided by ALSA to their
maximum, which we call 0dB.

This approach allows us to fit in with a slider system that has 0dB at
it's top end and we can also show the ALSA 0dB point as the "Base
Volume" in our UIs.

Now you could argue (which you obviously are) that the dB of the
underlying card should still be exposed in the purest sense, but that
does make for more complicated calculations and confusing repercussions
elsewhere, including the mapping from percentage to dB not being
consistent (e.g. sometimes 100% is 0dB, sometimes it's 12dB etc.).

You could also argue that any controls that go >0dB should just be
ignored by PA - i.e. we never control the mixers in a way that would go
over 0dB unless we're going above our 100%. That may be a more valid
approach, but it needs a standard way to represent volumes >100% which
would then fall into the zone of influence of your other current
bugbear: the range checking thing in alsa-lib/alsamixer. Ultimately this
boils down to the fact that the 0dB point in some alsa mixers is located
at a random percentage < 100%. This is fundamentally the problem we are
trying to combat and make it clear to the user where that point is.


So as I've said before, the current approach is IMO the best way to fit
in with the semantics currently available. If you change those semantics
and provide mechanisms to represent a tri-range (min, 100%/0dB, max)
then we could probably adjust to fit in with those semantics. But none
currently exist. So we'll stick with how it's done now for the time being.


Col
-- 

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

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]