[gstreamer-bugs] [Bug 571610] [pulsesink] Allow setting a log volume, instead of a linear one

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Wed Sep 9 16:05:47 PDT 2009


https://bugzilla.gnome.org/show_bug.cgi?id=571610



--- Comment #15 from Lennart Poettering <lennart at poettering.net> 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().

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.




More information about the Gstreamer-bugs mailing list