'Twas brillig, and Raymond Yau at 28/06/10 02:47 did gyre and gimble:
2010/6/23 Colin Guthrie gmane@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