Bug 493671 (Andrew)
Summary: | Erratic volume control after 5.3 upgrade | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Andrew D. <adebened> |
Component: | gstreamer | Assignee: | Benjamin Otte <otte> |
Status: | CLOSED WONTFIX | QA Contact: | desktop-bugs <desktop-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 5.3 | CC: | 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
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 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? 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. 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. 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. 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) 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. 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). |