Bug 493671 (Andrew)

Summary: Erratic volume control after 5.3 upgrade
Product: Red Hat Enterprise Linux 5 Reporter: Andrew D. <adebened>
Component: gstreamerAssignee: Benjamin Otte <otte>
Status: CLOSED WONTFIX QA Contact: desktop-bugs <desktop-bugs>
Severity: medium Docs Contact:
Priority: low    
Version: 5.3CC: aiden449, gilboooo, pankaj86
Target Milestone: rc   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-03 12:37:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Andrew D. 2009-04-02 15:44:12 UTC
Description of problem:
This occurred after upgrading to 5.3: Trying to change the volume with the sliders (either with the gnome applet or the volume control gui) sometimes causes the volume to go way down when you are trying to raise the volume (both with scroll-wheel and dragging the (master) sliders). The left-right bars also get unlocked sporadically. It is most prevalent when actually playing something like a movie (eg. with Xine) and trying to change the volume with the volume manager (master sliders) or the applet. It's especially noticeable if you are trying to change the volume quickly.

Specifically I am finding this behavior with

Bus 003 Device 002: ID 041e:3000 Creative Technology, Ltd SoundBlaster Extigy

(USB sound)

The following Fedora bugs seem similar (but are closed so I have opened this one for RHEL 5):

https://bugzilla.redhat.com/show_bug.cgi?id=431968 (comment number 1 is a good description)
https://bugzilla.redhat.com/show_bug.cgi?id=431969

Version-Release number of selected component (if applicable):
I dont know which components can be causing this but here are a few candidates:
gnome-media-2.16.1-3.el5
gstreamer-0.10.20-3.el5
gstreamer-tools-0.10.20-3.el5
gstreamer-plugins-base-0.10.20-3.el5
(plus plugins-good, plugins-bad


How reproducible:
On one machine always.


Steps to Reproduce:
1. Open a movie or audio file (eg. a movie with Xine).
2. Try to change the volume with the gnome volume applet.
3. Notice that volume slider behaves erratically.
  
Actual results:
Volume goes way down when you are trying to raise it. If you are using the volume panel, the master sliders become unlinked etc.

Expected results:
Volume should raise uniformly, master sliders should remain linked.

Additional info:
I have also reported this bug to CentOS.
http://bugs.centos.org/view.php?id=3478

Comment 1 Andrew D. 2009-04-02 16:44:50 UTC
Just an addition. It seems some information on the cause of this may be found here:

http://bugzilla.gnome.org/show_bug.cgi?id=478512

Comment 2 Andrew D. 2009-04-02 17:02:16 UTC
Sorry for all the posts. I just installed gnome-alsa-mixer (http://rpm.pbone.net/index.php3/stat/4/idpl/6027276/com/gnome-alsamixer-0.9.6-4.el5.i386.rpm.html) This seems to control the volume without the problems. Maybe it would be possible to point the panel applet to this program instead?

Comment 3 Andrew D. 2009-04-02 23:34:00 UTC
One more thing I found which I think will help isolate the problem. To try and isolate the problem, I replaced the /usr/lib/gstreamer-0.10/libgstalsa.so file with one from the package gstreamer-plugins-base-0.10.9-6.el5.i386.rpm (backing up the original libgstalsa.so, of course). Since doing this, the problem seems to have gone away.

Comment 4 pankaj pandey 2009-06-02 07:35:35 UTC
I was just about to create a new bug when i came upon this bug. As i have already written a lot for filing the bug i'll simply post it here.

Description of problem:
The sound volume is not synced between the application volume control and the applet

Version-Release number of selected component (if applicable):
gnome-media-2.26.0-6.fc11.x86_64
updated f11 2.6.29.4-167.fc11.x86_64
intel core2duo with intel 82801H (ICH8) audio controller, intel hda driver

How reproducible:
Always (on my machine)

Steps to Reproduce:
1. Open rhythmbox (only, dont keep any other player open), play some sound with all volumes full, Applet and rhythmbox both show 100% volume
2. Reduce rhythmbox to 50% by *scrolling* down with the mouse on the volume icon in rhythmbox
The applet shows a reduced volume of 93% (-6.02 dB)
3. *Scroll down* on the applet to reduce its volume further than 93%

Actual results:
1. Sound volume increases
2. Applet shows 99% sound volume (i.e. it reduced from 100% instead of reducing from 93%)
3. Rhythmbox shows 90% sound volume (i.e. it reduced from 100% instead of reducing from 50%)

Expected results:
1. Sound volume should decrease
2. Applet should be having 92% volume
2. Rhythmbox should have somewhat < 50% volume

Additional info:
The problem occurs only with changing the volume by srolling with the mouse on the icon and not setting it directly using the scrollbar that comes up when the icon is clicked
There is no linear relation between sound and the applet volume value
Rhythmbox volume corresponds to a somewhat linear relation between sound level and the shown volume level, hence i'm giving some comparison values
Rhythmbox    Applet
0            0
2            62
10           78
20           84
40           91
60           95
80           98
90           99
100          100
This causes a lot of problem insetting the application volume
Also when the volume is changed in the applet, rhythmbox reverts to the previous value when the next song comes to play.

Comment 5 Aiden 2009-08-21 23:30:43 UTC
I can confirm the erratic volume in Moveplayer and Rhythmbox when the sound server is both a local and remote pulse-audio recipient ... the following may be of interest:

Versions:
rhythmbox-0.12.3-1.fc11.x86_64
pulseaudio-0.9.15-14.fc11.x86_64

When the system *running* rhythmbox is playing, and the pulseaudio recipient is a remote machine ... volume jumps when changing tracks are much more erratic. The sink for that app in PulseAudio manager can jump to 1024% volume in some cases. The local PA volume control is consistent.

The volume jumps appear to occur when changing track, and with more frequency when changing track where the previous and new tracks are of differing formats or folders suggesting some init code somewhere is off-beat when examining volume levels.

Sometimes the volume mutes, but I am presuming the control shows mute but the jump is in-fact to 0% or -integer% indicating to the reading app of that value a muted state.

FFPlay when using SDL does not have the problem. Not really tried any other apps.

Comment 6 Gilbert Fernandes 2010-01-15 14:56:50 UTC
I have another problem but I don't know if I should open a new bug.

I have some MP3 files. I launch the Gnome Media Player, and put the files into the playing list. The first track plays.

When it goes to the second track, there's no sound. The file is playing in Gnome Media Player, but there's no sound at all and volume is a 100 %

The only way to recover sound is to go to the Gnome Media Player, click on the sound icon, move down then all the way up the lever, and suddenly the sound comes back ! :/

I have been having problems with sound since Fedora 11. On Fedora 11, the sound would go down 50 % each time a new track was played, and I have to keep moving the sound up all the time. And while a file was playing, and while I was moving the sound lever UP I could see the "system" move it down so I had to move it up 2 sometimes 3 times until it remained at 100 %

I have since moved to Fedora 12. Now, sound level remains at 100 % all the time, but between tracks sound is lost.

My uname -a :
Linux empire.chadelaud 2.6.30.10-105.fc11.i586 #1 SMP Thu Dec 24 16:26:26 UTC 2009 i686 athlon i386 GNU/Linux

I am using Gnome Media Player 0.9.8

My system is up to date (just launched yum update as root before reporting here, I got no update which means I have all the latest versions in the Fedora 12 repository right now)

Comment 7 RHEL Program Management 2014-03-07 12:12:56 UTC
Thank you for submitting this request for inclusion in Red Hat Enterprise Linux 5. We've carefully evaluated the request, but are unable to include it in the  last planned RHEL5 minor release. This Bugzilla will soon be CLOSED as WONTFIX. To request that Red Hat re-consider this request, please re-open the bugzilla via  appropriate support channels and provide additional business and/or technical details about its importance to you.

Comment 8 RHEL Program Management 2014-06-03 12:37:12 UTC
Thank you for submitting this request for inclusion in Red Hat Enterprise Linux 5. We've carefully evaluated the request, but are unable to include it in RHEL5 stream. If the issue is critical for your business, please provide additional business justification through the appropriate support channels (https://access.redhat.com/site/support).