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 340369 - [volume element] "volume" property range insufficient
[volume element] "volume" property range insufficient
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal minor
: 0.10.7
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-05-02 04:22 UTC by Артём Попов
Modified: 2006-05-03 13:33 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Description Артём Попов 2006-05-02 04:22:02 UTC 
Please describe the problem:
The "volume" property in the volume element has the maximum value of 4.

This could be insufficient in certain cases, i. e. when an audio file is very
quiet, the media player will try to raise the volume using replaygain
information. Together with pre-amplification, the requested value may exceed 4
or even 5.

I suggest raising the "volume" property maximum value to 10.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Wim Taymans 2006-05-03 08:58:40 UTC 
        * gst/volume/gstvolume.c: (volume_funcfind), (volume_set_caps),
        (volume_transform_ip):
        Increase "volume" property to 10.0. Fixes #340369.
        Set the process function to NULL when capsnego fails so that
        we properly error out.
Comment 2 Andy Wingo 2006-05-03 13:33:58 UTC 
I originally had it at 4 for automatically-generated guis, so that you wouldn't get a slider too big. However I don't think bounds information like that should be mapped to property bounds; it would be more correct to make the range unlimited. That would fix this bug for good.