After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 571610 - [playbin] Scale of volume property is not documented
[playbin] Scale of volume property is not documented
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal enhancement
: 0.10.25
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 567660
Blocks:
 
 
Reported: 2009-02-13 11:22 UTC by Bastien Nocera
Modified: 2009-09-15 18:04 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bastien Nocera 2009-02-13 11:22:49 UTC
Right now, when Totem or Rhythmbox changes the volume on the pulsesink, the values shown in those applications doesn't match what is shown in gnome-volume-control, or pavucontrol.

g-v-c and pavucontrol use the logarithmic volume, whereas pulsesink uses the linear volume.

It would be nice to either be able to switch between the 2 through a property, or have the logarithmic volume be the default.
Comment 1 Sebastian Dröge (slomo) 2009-02-14 09:17:09 UTC
A logarithmic volume would of course make more sense but unfortunately the "volume" property is like an interface that is used for example by playbin2. If it's found on an audio sink the volume property of playbin2 simply forwards to the volume property of the sink and no "volume" element is inserted.
We should probably change this in 0.11 everywhere and maybe also add some property description interface that could give some information about the unit that is used by properties (dB or linear scale factory, nanoseconds or milliseconds, ...).

For now you can simply convert by taking the logarithm:

dB = 20 log_10 (scale)
scale = 10**(dB/20)
Comment 2 Tim-Philipp Müller 2009-02-14 13:57:27 UTC
Guess this would better be done as part of an interface rather than more magic properties?
Comment 3 Sebastian Dröge (slomo) 2009-02-15 06:23:52 UTC
Yeah, an interface that gives additional information about a property like the unit that is used and some helper functions in gstaudio for dB<->scale conversion ;)
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2009-02-15 11:56:11 UTC
I have something like this in buzztard (BtPropertyMeta) - needs some more work though. The iface adds only one method so far to format a human readable string for a parameter. And it adds some extra flags that can be stored into the qdata of the paramspec. That would serve an alternative for all the flags that are more application hints and are not really used by gstreamer core itself. Like the MUTABLE_PLAYING from bug #571559 or UI_SKIP from #522205.

Comment 5 David Schleef 2009-02-15 20:04:34 UTC
We really could use a good GObject property replacement for 0.11 that takes all our needs into account.
Comment 6 Sebastian Dröge (slomo) 2009-02-16 11:03:54 UTC
s/GObject property/GObject/ ;) We should probably base GstObject directly on GType in 0.11 and make it threadsafe in all places first as the GObject maintainers don't think this is important... and while at that we could of course make properties more useful for our needs (I also want a GError for ::set_property for example).
Comment 7 Bastien Nocera 2009-09-03 15:07:35 UTC
To reiterate the problem.

The problem is that the volume in applications such as Rhythmbox and Totem, and in the volume controls wouldn't match.

For example: pavucontrol shows "39%" for Totem's volume, whereas Totem's tooltip on the volume control shows "6%". Those should match...
Comment 8 Sebastian Dröge (slomo) 2009-09-03 17:37:42 UTC
That problem would still exist then because every application probably wants to show the volume with a different scale. This can only be fixed by guidelines that everybody accepts and uses, for example that volumes should always be shown logarithmic (which makes most sense).

If that's the only problem you see in totem you can simply convert the linear volume into a logarithmic volume for totem ;)
Comment 9 Stefan Sauer (gstreamer, gtkdoc dev) 2009-09-03 17:44:42 UTC
Does pavucontrol use a logarithmic scale, if so please file a bug there as there is percent is not a logarithmic unit. It would be better to show the volume as db there in such a case.
Comment 10 Lennart Poettering 2009-09-04 02:33:14 UTC
PA actually uses "opaque" scales wherever possible, i.e. in an unspecified unit. This is needed because some hardware does not provide any dB information, so we really have no clue at all what the hardware volumes mean.

However, under some specially flagged conditions volumes are marked as "software" volumes in which case (and only in this case) they can be converted to dB or to linear via some utility functions that are part of the PA API.

The mapping between those "opaque" volumes and the linear factor has changed in the past. The "opaque" volume used to be logarithmic (i.e. basically a linear function of the dB scale), but nowadays is cubic in its mapping from the linear factors.

Confusing? Yes, a bit I guess.

The volume property Gst uses, which unit does it actually have? Is it a linear factor? If so, then it should be easy to fix the whole thing by simply converting the opaque volume to linear volumes. This should be safe in this since one of the conditions where this conversion is safe is if the volume is of a stream and not a device. Which is the case here.
Comment 11 Sebastian Dröge (slomo) 2009-09-04 05:02:14 UTC
(In reply to comment #10)
> PA actually uses "opaque" scales wherever possible, i.e. in an unspecified
> unit. This is needed because some hardware does not provide any dB information,
> so we really have no clue at all what the hardware volumes mean.
> 
> However, under some specially flagged conditions volumes are marked as
> "software" volumes in which case (and only in this case) they can be converted
> to dB or to linear via some utility functions that are part of the PA API.
> 
> The mapping between those "opaque" volumes and the linear factor has changed in
> the past. The "opaque" volume used to be logarithmic (i.e. basically a linear
> function of the dB scale), but nowadays is cubic in its mapping from the linear
> factors.
> 
> Confusing? Yes, a bit I guess.

Thanks for the explanations :)

> The volume property Gst uses, which unit does it actually have? Is it a linear
> factor? If so, then it should be easy to fix the whole thing by simply
> converting the opaque volume to linear volumes. This should be safe in this
> since one of the conditions where this conversion is safe is if the volume is
> of a stream and not a device. Which is the case here.

Yes, the GStreamer volumes are a simple linear factor.
Comment 12 Lennart Poettering 2009-09-09 22:31:34 UTC
Hmm, pulsesink actually does use the pa_sw_volume_to_linear() resp gst_pulse_cvolume_from_linear() to convert between that GST property and PA volumes. So I am nto sure what is going on here.
Comment 13 Lennart Poettering 2009-09-09 22:49:22 UTC
Hmm, Bastien, is this simply a presentation issue?

i.e. does Rhythmbox map the linear factor linearly to the pixels of the volume slider? That is not a good idea.

Mapping volume levels to pixels on screens is a science of its own. There are actually multiple standards about this, and they all suck.

After discussing this on LAD I decided to use cubic mapping in PulseAudio (as mentioned). And so should you in Rb/Totem, probably.

i.e. if gst gives you the volume as linear factor x, then do this for showing it on a GtkScale:

  gtk_range_set_value(GTK_RANGE(scale), cbrt(x));

And when passing the volume you read from a GtkScale to gst do this:

  x = gtk_range_get_value(GTK_RANGE(scale));
  x = x*x*x;

Also see:

http://www.robotplanet.dk/audio/audio_gui_design/
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2009-May/thread.html#23151
Comment 14 Bastien Nocera 2009-09-09 23:01:37 UTC
We just map the playbin(2) volume property to a linear scale. This doesn't just affect Rhythmbox or Totem, but all the applications that would be using playbin (or pulsesink).

You'd want the volumes set in the applications (usually from 0-100%) to match with the volume presented in volume control applications.
Comment 15 Lennart Poettering 2009-09-09 23:05:45 UTC
If the way I understand things as described in #13 is correct than there isn't really anything to fix in gst. If the 'volume' property  gst maintains is log or lin doesn't really matter much. It's just a matter of encoding. It has a little influence on the resolution and range of the volumes you can set, but this shouldn't matter at all for its uses.

So, this bug should probably be closed and two new ones be opened against totem and rb, requesting that the linear volumes gst passes to those apps are converted as suggested on presentation and converted back when volume changes take place.

It might make sense to beef up GtkVolumeButton a bit to include a function that enables cubic mapping for it. That would be a cleaner solution I guess than adding the conversion logic to both totem and rb.

I.e. something like this:

enum {
    GTK_VOLUME_BUTTON_LINEAR_MAPPING,
    GTK_VOLUME_BUTTON_CUBIC_MAPPING
} GtkVolumeButtonMapping;

void gtk_volume_button_set_mapping(GtkVolumeButton *vb, GtkVolumeButtonMapping mapping);

For compat reasons this would default to GTK_VOLUME_BUTTON_LINEAR_MAPPING. And if GTK_VOLUME_BUTTON_CUBIC_MAPPING is selected the cbrt(x) resp x*x*x conversions are done in gtk_scale_button_set_value() resp _get_value().
Comment 16 Lennart Poettering 2009-09-09 23:09:23 UTC
(In reply to comment #14)
> We just map the playbin(2) volume property to a linear scale. This doesn't just
> affect Rhythmbox or Totem, but all the applications that would be using playbin
> (or pulsesink).

That means that either the definition of playbin/pulsesink should be changed so that they provide 'pixel' volumes instead of linear ones. Or all the client apps get fixed not to show the value directly as the position of a volume slider.

Given that 'pixel' volumes are only suitable for presentation on screen and useless otherwise, I'd vote for doing the linear-to-pixel conversion in the clients, and not in gst.

> You'd want the volumes set in the applications (usually from 0-100%) to match
> with the volume presented in volume control applications.

If you use cubic mapping in rb/totem, then you will end up with exactly the same pixel positions as ther pa apps would.
Comment 17 Sebastian Dröge (slomo) 2009-09-10 05:44:22 UTC
Yes, so let's close this bug and let it be fixed in RB/totem. GStreamer volumes (as of today) are always a linear factor and nothing else.

Once GObject becomes powerful enough to add custom metadata to properties or bug #567660 is fixed (I'd vote for a property for selecting the scale or some helper functions to convert from/to other scales in that interface) applications might need to handle other scales though...
Comment 18 Ernst Sjöstrand 2009-09-10 07:43:24 UTC
Isn't this a problem because it's an API-break for an api that's supposed to be reasonably stable? Sure you can upgrade everything in sync, but then you should at least acknowledge the api break.

Using an old version of rythmbox with a new version of pulseaudio changes the behaviour from this:
Set soundcard to: 5% volume, set Rhythmbox to 80% volume gives:  ~4% volume.

New behaviour:
Set soundcard to: 5% volume, set Rhythmbox to 1% volume gives: 50% volume (which kills my ears on my software controlled USB speakers)

</rant>...
Comment 19 Bastien Nocera 2009-09-10 08:09:13 UTC
Frankly, it's getting to be a pain in the arse supporting pulsesink in applications, for something that's supposed to be a drop-in replacement.

Having special casing in the UI code isn't going to make this any better.
Comment 20 Wim Taymans 2009-09-10 08:50:27 UTC
I have no problem just keeping the 0 to 100 value and doing the scaling in pulsesink. 

I would expect that the application just maps the volume value to a slider and that any scaling needed to make the volume changes sound smooth and easy to handle in the specific sinks.
Comment 21 Sebastian Dröge (slomo) 2009-09-10 09:02:53 UTC
I don't get what the problem with *pulsesink* here is. It uses linear volumes like every other GStreamer element that provides a volume property.

The problem here was, that other application that don't use pulsesink but pulseaudio directly are using a different scale (logarithmic or cubic) and this looks different in the GUI. But that is to be fixed on the application side and nowhere else...
Comment 22 Bastien Nocera 2009-09-10 09:21:47 UTC
(In reply to comment #21)
> I don't get what the problem with *pulsesink* here is. It uses linear volumes
> like every other GStreamer element that provides a volume property.
> 
> The problem here was, that other application that don't use pulsesink but
> pulseaudio directly are using a different scale (logarithmic or cubic) and this
> looks different in the GUI. But that is to be fixed on the application side and
> nowhere else...

It would need to be fixed in _every single playbin/pulsesink using app_, and with special-casing for playbin using apps. That seems backwards to me, and defeats the point of abstraction layer.
Comment 23 Sebastian Dröge (slomo) 2009-09-10 09:49:42 UTC
Every playbin using app can assume that it gets linear volumes and can convert it to what it needs. If we choose to let all elements return logarithmic volume someone else will complain that it's inconsistent with $randomapp that uses a slider based on a linear or cubic volume. This problem will always be there.
Comment 24 Lennart Poettering 2009-09-10 13:11:46 UTC
(In reply to comment #19)
> Frankly, it's getting to be a pain in the arse supporting pulsesink in
> applications, for something that's supposed to be a drop-in replacement.
> 
> Having special casing in the UI code isn't going to make this any better.

This is no special casing. Having a volume slider that has a linear mapping between the linear factor an the pixels is *always* a bad idea.

That simple fact has nothing to with PA. Nothing at all.

If you present a volume slider on screen you should be using cubic mapping (or something similar). Regardless which backend you have.
Comment 25 Lennart Poettering 2009-09-10 13:35:44 UTC
If playbin did document that its 'volume' property is a linear value then it was simply a bug in Rb/Totem to show that as is.
Comment 26 Sebastian Dröge (slomo) 2009-09-10 14:51:03 UTC
(In reply to comment #25)
> If playbin did document that its 'volume' property is a linear value then it
> was simply a bug in Rb/Totem to show that as is.

Fine, that's what I was trying to say all the time ;) It's not documented though, but all elements that implement the volume-pseudo-interface (i.e. have a "volume" property) use linear volume. I guess that's only documented for the volume plugin... that should probably be documented as part of the interface from bug #567660.

I'll add a small comment to playbin(2)'s documentation though...
Comment 27 Sebastian Dröge (slomo) 2009-09-10 14:57:08 UTC
commit 662a31983f21a8c52f4dce8f817c06349b2ba1cc
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Thu Sep 10 16:55:31 2009 +0200

    playbin(2): Document that the volume property uses a linear scale
    
    Fixes bug #571610.