Bug 488532

Confirming this.  Pretty annoying.

totem-2.26.0-1.fc11.x86_64
gstreamer-0.10.22-3.fc11.x86_64
pulseaudio-0.9.15-3.test5.fc11.x86_64

The original bug (the errors from pulsesink) is fixed in totem-2.26.1-2, though there is still a problem with pulsesink giving us a lower and lower volume when switching tracks, and the start volume is already low.

This ends up with a muted stream. Reassigning to PA for that problem.

Note that those hacks are gone in totem 2.27.x though, and we use playbin2.

Hmm, I cannot reproduce this here. the volume stays stable

Lennart, since bastien fixed the totem portion of things, the reproducer is slightly different:

In totem, put the stream volume at say 2%.  HW volume is irrelevant.  Then feed it two tracks.  When switching between the tracks, stream volume will go to 0.

Note that this is probably not as critical as it was before, since people rarely if at all listen to streams at such low volumes... Previously, it would go from 100% down to mute, but now with the exception of really low volumes, it stays stable.

*** Bug 493764 has been marked as a duplicate of this bug. ***

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This bug also affects my system, and the system and application volume start much much higher than 2%.

I can not figure out what the internal volume control in Totem changes. It seems to affect the master volume in some way, but also changes something else. Even at 25%, Totem blasts louder than all my other apps at 90%.

*** Bug 508583 has been marked as a duplicate of this bug. ***

*** Bug 507218 has been marked as a duplicate of this bug. ***

$ rpm -q totem
totem-2.26.2-1.fc11.i586
(and 64-bit)

Totem still controls the *system* volume level. Why?

I've seen the opposite problem (volume going up with track changes) in both Totem and Miro. The problem seems to be some strange interaction between the application volume control and the master volume control. 

To clarify, it is the master volume that is getting raised. Frequently _higher_ than 100%. The fragile workaround I've stumbled upon is to set the master volume to 100% before starting either of these apps.

*** Bug 498158 has been marked as a duplicate of this bug. ***

I am also experiencing erratic volume levels:

- a lot of the time, Rhythmbox will somehow get muted when I change tracks
- touching the slider in Rhythmbox will make the volume increase a LOT

I'm on a ThinkPad x61 running F-11 x86_64 in case it matters.

I really think this should be re-assigned to pulseaudio, because I'm having the same problems not only in totem but also in rhythmbox after the update to rhythmbox-0.12.3-1.fc11.

Same problem here: since the update to rhythmbox-0.12.3-1.fc11 rhythmbox also has the desribed problem.

(In reply to comment #15)
> I really think this should be re-assigned to pulseaudio, because I'm having the
> same problems not only in totem but also in rhythmbox after the update to
> rhythmbox-0.12.3-1.fc11.  

I agree (for what it's worth, which is probably not much) because the same problem exists when using audacious (https://bugzilla.redhat.com/show_bug.cgi?id=498158).  Lennart marked my bug as a duplicate of this one.

This problem also exists in Banshee, although it has been there for much longer now.
It probably is related to the fact that Banshee opens a new Stream for each song it plays.

It seems that exaile is not affected from this problem.

The original bug that I filed (https://bugzilla.redhat.com/show_bug.cgi?id=507218) has two video attachments documenting behavior for totem and rhythmbox where volume will increase during track playback and then revert.

-brent

Having the same erratic volume changes between tracks

pulseaudio-0.9.15-14.fc11.x86_64
xmms-1.2.11-5.20071117cvs.fc11.x86_64

xmms is configured to use pulseaudio.

The volume drops around 50% of the full range when changing tracks.  The user experience is that xmms plays one song and breaks.

Additionally, the system volume and app volume are identical.  This is insufficient behavior, as it means I can't adjust the volume of apps relative to each other.  Often tracks from different sources have different baseline volumes.

I would rather not boot into windows to enjoy both a classical music stream and podcasts simultaneously, or music while gaming.

Just adding a "me too" that I'm hitting this with:

pulseaudio-0.9.15-14.fc11.x86_64
rhythmbox-0.12.3-1.fc11.x86_64
gstreamer-0.10.24-1.fc11.i586

it's really quite frustrating

Has anybody found a workaround for this. It's driving me nuts.

The workaround is 'yum remove \*pulseaudio\*'.

Not sure if Lennart is actually working on this, because the only feedback from him was "cannot reproduce" and this was already more than 4 months ago.

Lennart, please tell us what you need to debug this. I'm sure we all are happy to provide the necessary info.

(In reply to comment #24)
> Has anybody found a workaround for this. It's driving me nuts.  

I have a fragile, partial workaround for my setup. On my htpc box, the problem is particularly bad. For me the workaround seems to be a matter of keeping the right balance of volume levels between the master volume and the app specific volume (for those apps, like Miro, that have one).

On my htpc box, I find I need to set my master volume to 100% before starting Miro, and keep the Miro volume at a fairly low level. On my laptop, things are more forgiving, not sure why. For me, keeping 100% master volume isn't really a problem b/c in both cases I have control over external amplification (via tv volume for the htpc and thinkpad volume buttons on the laptop).

(In reply to comment #4)
> Lennart, since bastien fixed the totem portion of things, the reproducer is
> slightly different:
> 
> In totem, put the stream volume at say 2%.  HW volume is irrelevant.  Then feed
> it two tracks.  When switching between the tracks, stream volume will go to 0.  

So, in rawhide, this is back to the way it was before.  Any volume level will  reduce the volume by abuot when you switch to the next track

I just watched it go from 88% -> 77% -> 67% -> 59% -> 51% -> 45%

alsa-plugins-pulseaudio + setting xmms output to alsa module works fine, no volume changes with track changes.

I haven't checked for other side effects, and I've only worked around with one application.

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


Also bugid 493671 *might* be related.

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.

Can anyone reproduce this on F12/rawhide?

I am pretty sure most of this is caused by various volume feedback loops in rb/totem/g-v-c/g-v-c-a/g-s-m. I'd like to track this down, which is much easier on Rawhide because in Rawhide PA's debug output includes messages that help tracking down loops like that. However I am unable to reproduce the issue at all there. Rhythmbox does not change the volume of between streams at all, doesn't even close/create a new one. Totem crashes every 5s so I cannot test it.

Anyone can give me a hint how I could reproduce this on Rawhide? Or is this an F11-only issue?

Lennart, yes I've been saying it's rawhide only.

Basically the problem I've been having is that in rawhide, either audio does not work at all (such is the case in today's rawhide), or when it does work, switching tracks quietens the audio.

Easy reproducer for this, the quieting bug:

Have a directory full of .flac files (it helps if they are short tracks)
Launch totem
Tell it to play every file
Take note of your volume level.
To save time, manually move the slider to within a few seconds of the end of the track
When the track switches, the volume will decrease by a magic number of the day.  I've seen it go from 100% -> 0% on one track.  Other times, it will go down by about 10% each track.

(In reply to comment #31)
> Lennart, yes I've been saying it's rawhide only.
> 
> Basically the problem I've been having is that in rawhide, either audio does
> not work at all (such is the case in today's rawhide), or when it does work,
> switching tracks quietens the audio.

Not work at all? What do you mean by that? Do applications think they play audio (i.e. playback time advances...) and you cannot hear anything? Do you get any error mesages? Please post that in a seperate bug.

> Easy reproducer for this, the quieting bug:
> 
> Have a directory full of .flac files (it helps if they are short tracks)
> Launch totem
> Tell it to play every file
> Take note of your volume level.
> To save time, manually move the slider to within a few seconds of the end of
> the track
> When the track switches, the volume will decrease by a magic number of the day.
>  I've seen it go from 100% -> 0% on one track.  Other times, it will go down by
> about 10% each track.  

Hmm, I have no flac files and Totem crashes on my after 2s already...

Hmm, no luck here. I am tempted to say that this is g-v-c's fault. If you make sure g-v-c and g-v-c-a are dead, can you reproduce this?

Also, could you run "pulseaudio -vvvvv" in a terminal please (run pulseaudio -k first to kill the running instance. To not race against respawning you might want to put "autospawn=no" in ~/.pulse/client.conf). If you do this with a rawhide's current PA you should see lines like this printed in the debug output:

"protocol-native.c: Client gnome-volume-control changes volume of sink Playback Stream."

This will tell you which process might change the volume on the track changes. (in this case it is g-v-c). Could you check if you see any lines like that that might give us a hint?

Hmm, OK. While I was not able to reproduce the actual problem I did find that totem resets the stream volume on every single track change. So this bug when it occurs is probably a rounding issue (i.e. converting PA's 16 bit volumes to gst's 0..100 volume, to the GtkScale and back) Totem should not do things like that. It should only feedback volume changes of the user to PA, and nothing else.

Reassigning to totem.

(In reply to comment #33)
> I am tempted to say that this is g-v-c's fault. If you make
> sure g-v-c and g-v-c-a are dead, can you reproduce this?

Yes, also happens in Xfce when there is no instance of g-v-c running.

(In reply to comment #34)
> Reassigning to totem.

What makes you think it's totem if users report this to happen with rhythmbox, banshee and xmms as well?

Assigning back to pulseaudio.

Christoph, rb has a similar feedback loop apparently. And as mentioned in my last message this prob is in totem, not g-v-c.

Hmm, Banshee fails to install on rawhide. cannot test.

if you manage to reproduce this, could you check if you get any messages as described in #33?

"Lennart, yes I've been saying it's rawhide only."

This is not a rawhide only bug.

I'm running F11 and am also experiencing this.  

pulseaudio-0.9.15-14.fc11.x86_64
rhythmbox-0.12.3-1.fc11.x86_64
gstreamer-0.10.24-1.fc11.i586

Experiencing the same symptoms in F11. Same versions of the same software. Volume drops each song.

Still occuring on F11 for me, updated fresh install on a different system.

using xmms with output to pulseaudio, volume dropped 32%, 74% -> 42%
using xmms with output to alsa, volume didn't change.


alsa-plugins-pulseaudio-1.0.20-2.fc11.x86_64
xmms-1.2.11-7.20071117cvs.fc12.x86_64
pulseaudio-0.9.15-17.fc11.x86_64

I think I updated xmms to rawhide after a potential fix was added, I can downgrade if that will provide any useful data.

*** Bug 523085 has been marked as a duplicate of this bug. ***

Same problem here.

pulseaudio-0.9.15-17.fc11.x86_64
gstreamer-0.10.24-1.fc11.x86_64
totem-2.26.3-3.fc11.x86_64

me hates pulseaudio

See my comments in bug 501972

I'd be interested to see what hardware people are seeing this problem with.  With an Audigy 2, I see this bug.  With on-board audio, I see bug 501972 instead.  I think that they're both related with how the audio level is getting set by totem and rhythmbox.

I cannot reproduce this in banshee with the on-board audio.  The comments in 501972 imply that with banshee that bug (which I think is the same) only happens after some track changes, not all.

Bug 510499 is probably a duplicate of this one.  I didn't file it that way initially because Bill (I think) said that rhythmbox was fine for him.

I experience volume going down with the on-board intel-hda (Intel Corporation 82801H).

There were 3 bugs here.

One was that gnome-media (and its various front-ends) had feedback loops problems. This should be fixed in the updated gnome-media available in F-11.

Another bug was that Totem itself was feeding back PulseAudio's volume to it on startup. This is fixed in totem-2.26.3-5.

Finally, there's a bug in pulsesink which causes applications to have lower and lower volume. This bug still exists and is upstream at:
https://bugzilla.gnome.org/show_bug.cgi?id=595231

If you still encounter those problems, please file a separate bug against the front-end that you're using, and mention the versions of:
- gnome-media
- pulseaudio
- the front-end in question

Also check whether disabling all (or one) of the running volume front-ends works:
- killall gnome-volume-control-applet
- disable /apps/gnome_settings_daemon/plugins/media-keys/active in GConf to disable the volume keys

Closing this bug as WORKSFORME because I cannot reproduce the problem with an updated F11, apart from the small pulsesink related volume changes.

Don't close it. 
The actual bug reported by the original post in here is: 
"each time totem advances to next track volume goes down a bit".
This is what people will go for when they search bugzilla for this bug. And it is NOT fixed. You stated it yourself! 
The fact it is reported upstream doesn't make it less of a bug!


How is it "works for me" when:
 -) it didn't work for anyone else, then an update came, which hopefully fixes it (should be "fixed" at least)
 -) you said "I cannot reproduce the problem with an updated F11, apart from the small pulsesink related volume changes." So you CAN reproduce it. And it DOESN'T work for you!

(In reply to comment #48)
> Don't close it. 
> The actual bug reported by the original post in here is: 
> "each time totem advances to next track volume goes down a bit".
> This is what people will go for when they search bugzilla for this bug. And it
> is NOT fixed. You stated it yourself! 
> The fact it is reported upstream doesn't make it less of a bug!

No, but you can track it there.

> How is it "works for me" when:
>  -) it didn't work for anyone else, then an update came, which hopefully fixes
> it (should be "fixed" at least)
>  -) you said "I cannot reproduce the problem with an updated F11, apart from
> the small pulsesink related volume changes." So you CAN reproduce it. And it
> DOESN'T work for you!  

I can reproduce small changes which don't warrant a big hoopla which you seem to make it. And read comments properly before going on beserk on bugs.

(In reply to comment #49)
> (In reply to comment #48)
> > Don't close it. 
> > The actual bug reported by the original post in here is: 
> > "each time totem advances to next track volume goes down a bit".
> > This is what people will go for when they search bugzilla for this bug. And it
> > is NOT fixed. You stated it yourself! 
> > The fact it is reported upstream doesn't make it less of a bug!
> 
> No, but you can track it there.

Marking it closed in fedora will confuse the users that experience the problem into thinking it have been fixed. 
Other bugtracking systems (such as launchpad) provide functionality to track upstream. The lack of it here doesnt mean we should lie to the users.


> > How is it "works for me" when:
> >  -) it didn't work for anyone else, then an update came, which hopefully fixes
> > it (should be "fixed" at least)

You didn't answer this part.
"Works for me" basically means "you who confirmed and appended this rapport are all idiots, this was never a bug" (https://bugzilla.redhat.com/page.cgi?id=fields.html#status). Is that what you try to accomplish here?


> I can reproduce small changes which don't warrant a big hoopla which you seem
> to make it. And read comments properly before going on beserk on bugs.  

Okay, so its a small boog. Lets ignore all of the small boogs. After all they dont cause the users any nerve. They are soo small and we can call them cute names.
If you think this thread is not appropriate for the actual problem reported (which still is the volume going down a bit) you should start a new bug while closing this one. 
The fact is: there is a bug in fedora and redhat buggzilla says there is not.
It actually explicitly states that this problem is not a bug. 

Its not a matter of this particular bug, but rather the policy. Is that what should be expected from fedoras QA? Is closing upstream reported bugs part of the policy?

Sigh. I'm not interested in having a discussion about the merits of choosing one resolved status over another. Re-read comment #47 and file a separate bug if you see a problem that's not the upstream problem mentioned.

Other users seem to be able to read comments before causing a fuss, I suggest you take your cue from that behaviour.

Closing as UPSTREAM to avoid disputes ( http://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow ).
Added reference to the GNOME bug report.

To be honest, I couldn't reproduce the problem at the time I closed the bug, and the deviation ended up being more severe than I'd previously encountered.

Lennart managed to fix the problem in pulsesink. Errata coming shortly, test thoroughly.

*** Bug 510499 has been marked as a duplicate of this bug. ***

*** Bug 501972 has been marked as a duplicate of this bug. ***

A fix in GStreamer doesn't fix the other audio players, which don't use GStreamer but which are affected by these issues with volume going down. e.g. XMMS and Audacious. Or does it?

https://bugzilla.redhat.com/show_bug.cgi?id=498158#c6

[...]

With bug 529562 I've just received a report about this in Audacious, and upstream has killed the pulseaudio plugin. This is getting funny.

gstreamer-plugins-good-0.10.16-4.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/gstreamer-plugins-good-0.10.16-4.fc11

I've tested the last update (gstreamer-plugins-good-0.10.16-4) on Fedora 11 x86_64 and now each time the track is changing, totem playing is blocked during a long long time (5 minutes for me)

(In reply to comment #58)
> I've tested the last update (gstreamer-plugins-good-0.10.16-4) on Fedora 11
> x86_64 and now each time the track is changing, totem playing is blocked during
> a long long time (5 minutes for me)  

Which is very unlikely to be related, though you should file a separate bug about it.

(In reply to comment #59)
> (In reply to comment #58)
> > I've tested the last update (gstreamer-plugins-good-0.10.16-4) on Fedora 11
> > x86_64 and now each time the track is changing, totem playing is blocked during
> > a long long time (5 minutes for me)  
> 
> Which is very unlikely to be related, though you should file a separate bug
> about it.  

Yes you're right.
the problem with lower volume seems ok now (based on percent value, before and after the track change)

I am still able to reproduce the exact issues described in comment #20 of Bug 501972, using those exact steps. This was using the updated gstreamer-plugins-good:

gstreamer-plugins-good-0.10.16-4.fc11.x86_64
rhythmbox-0.12.3-1.fc11.x86_64
pulseaudio-0.9.15-17.fc11.x86_64

I still get this problem playing flacs with

gstreamer-0.10.25-1.fc11.x86_64
gstreamer-plugins-good-0.10.16-2.fc11.x86_64
totem-2.26.3-6.fc11.x86_64
pulseaudio-0.9.15-17.fc11.x86_64

gstreamer-plugins-good-0.10.16-4.fc11, totem-2.26.4-2.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update gstreamer-plugins-good totem'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10747

I am having this problem.

I have a Fedora 11 with all updates.
I use :
- gstreamer 0.10.25-4.fc11
- gstreamer-plugins-good 0.10.16-1.fc11
- totem 2.26.3-5.fc11
- pulseaudio 0.9.15-17.fc11

I have a folder with MP3 files. I add them to the Gnome Player.
When it moves from one track to another, volume is muted.

On the upper bar, the volume (set at 100 %) goes to 0 and a little red cross appears to show it's muted.

I move it again to the max. On next track, it goes to 0 % again.

I then used note #63 and installed the update with versions :

- gstreamer-plugins-good-0.10.16-2.fc11.i586.rpm   
- totem-2.26.3-6.fc11.i586.rpm    
- totem-nautilus-2.26.3-6.fc11.i586.rpm

And the problem is still there. Instead of having the volume going to 0 as soon a track changes, the volume goes down by about one third.

After three tracks, the volume is again at 0.

I have to move up by 1/3rd the volume between tracks now instead of having to move it from 0 to 100 %

Using:
gstreamer-0.10.25-1.fc11.x86_64
gstreamer-plugins-good-0.10.16-4.fc11.x86_64
totem-2.26.4-2.fc11.x86_64

When I use totem to play multiple FLACs, totem freezes at 0:04 of every file after the first file.

So, I don't really know if the volume goes down, because totem seems to just stop.

I can add that this problem (Flac freeze) affects Exaile too since the last upgrade (gstreamer-plugins-good-0.10.16-4.fc11.x86_64)

I had the same problem until I updated gstreamer-plugins-base to this version:

gstreamer-plugins-base-0.10.25-2.fc11.x86_64

I know the title here is with reference to Totem and I apologize upfront if the following is spam but I wasnt sure what would be relevant but this definitely sounds like the exact same problem and I question if it has anything to do specifically with Totem. When using audacious and I hit "next" the volume will consistently every time drop by some amount or all the way to 0. Additionally it tends to pause for approximately 5 seconds before advancing when I press next. The pause does not happen when the tracks advance automatically. The volume though occasionally does drop but I think its related to a prior manual action. In any case this Im having the same problems with audacious as described in this ticket. I have a fully updated system as of this morning (2009-10-28 7:27am MDT). I did notice my plugins-base is not -2 and repeated attempts to update via the repos has no hit. Is that a "beta" rpm?

audacious-plugins-wavpack-1.5.1-10.fc11.x86_64
audacious-libs-1.5.1-11.fc11.x86_64
audacious-plugins-freeworld-aac-1.5.1-2.fc11.x86_64
audacious-plugins-vortex-1.5.1-10.fc11.x86_64
audacious-plugins-freeworld-mms-1.5.1-2.fc11.x86_64
audacious-plugins-metronome-1.5.1-10.fc11.x86_64
audacious-plugins-freeworld-tta-1.5.1-2.fc11.x86_64
audacious-plugins-arts-1.5.1-10.fc11.x86_64
audacious-plugins-freeworld-mp3-1.5.1-2.fc11.x86_64
audacious-plugins-freeworld-1.5.1-2.fc11.x86_64
audacious-plugins-1.5.1-10.fc11.x86_64
audacious-plugins-esd-1.5.1-10.fc11.x86_64
audacious-plugins-amidi-1.5.1-10.fc11.x86_64
audacious-plugins-freeworld-alac-1.5.1-2.fc11.x86_64
audacious-plugins-freeworld-wma-1.5.1-2.fc11.x86_64
audacious-plugins-uade-2.09-5.fc11.x86_64
audacious-plugins-jack-1.5.1-10.fc11.x86_64
audacious-1.5.1-11.fc11.x86_64
gstreamer-plugins-ugly-0.10.12-2.fc11.x86_64
totem-gstreamer-2.26.3-3.fc11.x86_64
gstreamer-tools-0.10.25-1.fc11.x86_64
gstreamer-plugins-good-0.10.16-1.fc11.x86_64
gstreamer-plugins-schroedinger-1.0.7-1.fc11.x86_64
PackageKit-gstreamer-plugin-0.4.9-1.fc11.x86_64
gstreamer-plugins-bad-extras-0.10.13-7.fc11.x86_64
gstreamer-0.10.25-1.fc11.x86_64
gstreamer-plugins-flumpegdemux-0.10.15-6.fc11.x86_64
gstreamer-plugins-base-0.10.25-1.fc11.x86_64
gstreamer-plugins-bad-0.10.13-7.fc11.x86_64
gstreamer-ffmpeg-0.10.8-1.fc11.x86_64
gstreamer-python-0.10.16-1.fc11.x86_64
pulseaudio-libs-0.9.15-17.fc11.i586
pulseaudio-0.9.15-17.fc11.x86_64
pulseaudio-libs-glib2-0.9.15-17.fc11.x86_64
pulseaudio-utils-0.9.15-17.fc11.x86_64
wine-pulseaudio-1.1.29-1.fc11.i586
pulseaudio-libs-0.9.15-17.fc11.x86_64
alsa-lib-1.0.21-3.fc11.i586
alsa-lib-1.0.21-3.fc11.x86_64
alsa-utils-1.0.21-2.fc11.x86_64
bluez-alsa-4.42-5.fc11.x86_64

gstreamer-plugins-base-0.10.25-2.fc11, gstreamer-plugins-good-0.10.16-4.fc11, totem-2.26.4-2.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update gstreamer-plugins-base gstreamer-plugins-good totem'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10747

Volume is still going crazy. Upgrading to the latest gstreamer yesterday (supposedly fixing this bug?) made things WORSE.

I just came here through #501972.

In my case I have two issues with the volume:

1) Totem
It seems that every time I open a different video (Movie -> Open) the volume in Kmix goes up about 2%. (ex: 88% -> 90%)

2) Rhythmbox
On this one, *every time I change a music manually*, by clicking on it on the playlist, the volume goes up to 100%. It's actually what Kmix says, but in reality it seems to *over use* the sound card capability. The song sounds very high and the quality of it is all crap. (Not sure how to explain it in English, but in Brazil we usually use the word 'exploding' (the speakers) for that behavior)

I'm using KDE in a F11 x86_64 updated box , even with FEDORA-2009-10747 updates mentioned above.
Laptop: Dell Vostro 1310

BTW, Amarok and Kaffeine works fine though.

[diegobz@rasther ~]$ rpm -qa kernel\* rhythmbox\* totem\* \*pulse\* pad\* pav\* \*alsa\*
kernel-devel-2.6.30.5-43.fc11.x86_64
totem-nautilus-2.26.4-2.fc11.x86_64
xine-lib-pulseaudio-1.1.16.3-2.fc11.x86_64
kernel-2.6.30.9-90.fc11.x86_64
pulseaudio-libs-0.9.15-17.fc11.x86_64
pulseaudio-module-bluetooth-0.9.15-17.fc11.x86_64
alsa-utils-1.0.21-2.fc11.x86_64
kernel-devel-2.6.30.8-64.fc11.x86_64
totem-mozplugin-2.26.3-5.fc11.x86_64
alsa-lib-1.0.21-3.fc11.i586
pulseaudio-libs-0.9.15-17.fc11.i586
kernel-2.6.30.5-43.fc11.x86_64
pulseaudio-0.9.15-17.fc11.x86_64
wine-alsa-1.1.29-1.fc11.x86_64
pulseaudio-module-x11-0.9.15-17.fc11.x86_64
alsa-lib-1.0.21-3.fc11.x86_64
padauk-fonts-2.4-3.fc11.noarch
kerneloops-0.12-5.fc11.x86_64
totem-gstreamer-2.26.4-2.fc11.x86_64
pulseaudio-libs-glib2-0.9.15-17.fc11.x86_64
kernel-firmware-2.6.30.9-90.fc11.noarch
kernel-headers-2.6.30.9-90.fc11.x86_64
wine-pulseaudio-1.1.29-1.fc11.x86_64
kernel-2.6.30.8-64.fc11.x86_64
kernel-devel-2.6.30.9-90.fc11.x86_64
alsa-plugins-pulseaudio-1.0.21-2.fc11.x86_64
kde-settings-pulseaudio-4.2-12.1.noarch
wine-pulseaudio-1.1.29-1.fc11.i586
totem-pl-parser-2.26.2-2.fc11.x86_64
pulseaudio-utils-0.9.15-17.fc11.x86_64
rhythmbox-0.12.3-1.fc11.x86_64
totem-2.26.4-2.fc11.x86_64

I thought it got better after an upgrade but then I realized that it worked only because another application was using pulse at the same time and the - btw, totally fucked up - pulse volume controls caused the main volume (or whatever this is supposed to be) knob to be set at 100%.

So to recoup, start another application that connects to the pulse server at all times (for me it is the npviewer.bin crap), open sound preferences, set the other application volume level to max, make sure 'output volume' is at at 100%. Now you can control the volume for totem without moving the 'output volume knob', which works around this bug.

gstreamer-plugins-base-0.10.25-2.fc11,totem-2.26.4-2.fc11,gstreamer-plugins-good-0.10.16-4.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/gstreamer-plugins-base-0.10.25-2.fc11,totem-2.26.4-2.fc11,gstreamer-plugins-good-0.10.16-4.fc11

I confirm the totem issue fixed for me with 

gstreamer-plugins-base-0.10.25-2.fc11,
totem-2.26.4-2.fc11,
gstreamer-plugins-good-0.10.16-4.fc11

gstreamer-plugins-base-0.10.25-2.fc11, totem-2.26.4-2.fc11, gstreamer-plugins-good-0.10.16-4.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update gstreamer-plugins-base totem gstreamer-plugins-good'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10937

Created attachment 367476 [details]
Volume discrepancy among different apps

I'm using the latest build on koji (03-11-2009) of the following packages:

gstreamer-plugins-base-0.10.25-2.fc11
totem-2.26.4-2.fc11
gstreamer-plugins-good-0.10.16-5.fc11

It seems the apps can't keep in sync with that master channel of kmix. Different behaviors are noticed if different actions are done, like scrolling down/up on the kmix icon in the tray, moving down/up the vertical bar of kmix or others apps.

In my case, if the last change on the volume was done in Rhythmbox, I can change the tracks without getting the sound output overhead. But once I change the volume in the kmix, that behavior happens again. It's probably related to the fact that kmix volume is 49% higher than Rhythmbox, which is 4%, although it's not always that range.

(In reply to comment #76)
> Created an attachment (id=367476) [details]
> Volume discrepancy among different apps
> 
> I'm using the latest build on koji (03-11-2009) of the following packages:
> 
> gstreamer-plugins-base-0.10.25-2.fc11
> totem-2.26.4-2.fc11
> gstreamer-plugins-good-0.10.16-5.fc11
> 
> It seems the apps can't keep in sync with that master channel of kmix.
> Different behaviors are noticed if different actions are done, like scrolling
> down/up on the kmix icon in the tray, moving down/up the vertical bar of kmix
> or others apps.
> 
> In my case, if the last change on the volume was done in Rhythmbox, I can
> change the tracks without getting the sound output overhead. But once I change
> the volume in the kmix, that behavior happens again. It's probably related to
> the fact that kmix volume is 49% higher than Rhythmbox, which is 4%, although
> it's not always that range.  

Rhythmbox in F-11 wasn't updated to use the cubic stream volume, though that's done in F-12.

And you won't ever get kmix to agree with PulseAudio on volume levels, as PulseAudio uses multiple channels to achieve its volume.

Anyway, this has nothing to do with this bug.

> Rhythmbox in F-11 wasn't updated to use the cubic stream volume, though that's
> done in F-12.

So do you mean we CAN'T use PulseAudio and Rhythmbox properly on F11 anymore?
 
> And you won't ever get kmix to agree with PulseAudio on volume levels, as
> PulseAudio uses multiple channels to achieve its volume.

Indeed. But it sucks by the fact that changing the *Rhythmbox app* volume, it reflects on the master channel of Kmix (wrongly). That's my concern and what I tried to point out.

From where I see, changing an *app* volume either should just change the levels of its on channel or, if it reflects the master channel, then the volume levels should be exactly the same, which I think is not the case.

> Anyway, this has nothing to do with this bug.  

Should I file another bug then?

(In reply to comment #78)

> Should I file another bug then?  

Yes, go ahead please. Nether your information nor your tone are helpful for this bug.

I use AMAROK and phonon uses the xine backend. I had this experience: (from bug 501972)




Comment #9 From  Need Real Name (caterpillar)  2009-06-21 09:49:48 EDT   (-) [reply] -------

I've just experimented this shocking bug of having SUDDENDLY the volume at 100%

I was on my bed with headphones listening to music and reading a book (so,
without touching the computer) and SUDDENDLY the volume was setted to 100%

Please fix carefully this bug, it can damage ear of users! Imagine a Sennheiser
hd595 at 100% volume >:8 I'm still shocked.

Now, here informations about my computer.

Kde 4.2.3
Amarok 2.0.2

Opened programs while the bug happened:
Opera 10 beta1
Amarok (of course, I was listening to music with it)
Skype
Kopete
Emesene

[Caterpillar@Magic-3 ~]$ cat /etc/fedora-release
Fedora release 11 (Leonidas)

[Caterpillar@Magic-3 ~]$ uname -a
Linux Magic-3 2.6.29.4-167.fc11.i586 #1 SMP Wed May 27 17:14:37 EDT 2009 i686
athlon i386 GNU/Linux

[Caterpillar@Magic-3 ~]$ rpm -qa kernel\* \*firefox\* \*pulse\* pad\* pav\*
\*alsa\* nsplug\*

wine-pulseaudio-1.1.21-2.fc11.i586
xine-lib-pulseaudio-1.1.16.3-2.fc11.i586
pulseaudio-0.9.15-11.fc11.i586
pulseaudio-module-x11-0.9.15-11.fc11.i586
kernel-2.6.27.24-170.2.68.fc10.i686
kernel-devel-2.6.29.4-167.fc11.i586
alsa-utils-1.0.20-3.fc11.i586
pulseaudio-module-bluetooth-0.9.15-11.fc11.i586
padauk-fonts-2.4-3.fc11.noarch
alsa-lib-1.0.20-1.fc11.i586
kernel-2.6.29.4-75.fc10.i686
kernel-2.6.29.4-167.fc11.i586
pulseaudio-libs-glib2-0.9.15-11.fc11.i586
alsa-plugins-pulseaudio-1.0.18-3.fc11.i586
kernel-headers-2.6.29.4-167.fc11.i586
kerneloops-0.12-5.fc11.i586
kernel-firmware-2.6.29.4-167.fc11.noarch
pulseaudio-libs-0.9.15-11.fc11.i586
pulseaudio-utils-0.9.15-11.fc11.i586
kde-settings-pulseaudio-4.2-10.20090430svn.fc11.noarch
nspluginwrapper-1.3.0-5.fc11.i586
firefox-3.5-0.20.beta4.fc11.i586
pavucontrol-0.9.8-1.fc11.i586

(In reply to comment #80)
> I use AMAROK and phonon uses the xine backend. I had this experience: (from bug
> 501972)

If you're using the xine-lib backend, then it's nothing to do with this bug.

gstreamer-plugins-base-0.10.25-2.fc11, totem-2.26.4-2.fc11, gstreamer-plugins-good-0.10.16-4.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

(In reply to comment #81)
> (In reply to comment #80)
> > I use AMAROK and phonon uses the xine backend. I had this experience: (from bug
> > 501972)
> 
> If you're using the xine-lib backend, then it's nothing to do with this bug.  

so the audio volume that goes up suddendly is originated by a bug of xine-lib backend?

(In reply to comment #82)
> gstreamer-plugins-base-0.10.25-2.fc11, totem-2.26.4-2.fc11,
> gstreamer-plugins-good-0.10.16-4.fc11 has been pushed to the Fedora 11 stable
> repository.  If problems still persist, please make note of it in this bug
> report.    

Yes.

I believe I just hit this with versions greater than or equal to those.

And then I just updated, i.e. to gst-pl-base-0.10.25-3, and still see 'wonkiness' though haven't seen the earsplitting >130% gain situation.

What I'm still seeing is my pulse volume panel widget, when I click various songs on rhythmbox, go up briefly (one extra arc that appears and disappears next to the speaker icon).  I.e. each new song it does that.  Sometimes dropping by 20%.  So I'm still scared #&*!@(less that I'll suffer the 138% pain again.

But note, I am one of those freaks who runs f11 gst-mixer to enable line monitoring so that I can use a usb video grabber to watch pc on my tv.  I know that somehow makes me a corner case not worth supporting in that regard (and yes, the pulse module-loopback does introduce latency and is not a solution.  The solution I've settled on is to stop watching TV when before I upgrade to f12.  I wish that actually upset me and it wasn't the content on TV that was driving that choice).

I also do all kinds of other stuff playing with jack under pulse audio, though my intention is for my configuration to be 'stock', when I noticed this bug.

Still, I consider this bug a serious HEALTH HAZARD, and have suffered real PAIN because of it.  Yes, not even the implied warranty of fitness for a particular purpose, I get it.

I also get that my real complaint is with sony and whatever hardware can drive my earbuds to that level of pain, no matter how buggy the software.

Sigh...  Probably my fault, something I'm missing, something I've horribly misconfigured.  Me and whatever freak configuration I have where kqemu speeds up my virtualized tasks by >100% even though the host and guest are kernel 2.6.

Sigh, I'm about at the point where I'm ready to reinstall my OS to get back to the week(s) of stable non-pain not-hitting this bug.  They kind of strategy I thought I managed to give up along with microsoft winblowz.  I have this feeling that if I judiciously never touch the rhythmbox volume meter, and never click on the crossfade plugin, and never run gst-mixer, that I won't run into this.

...

edit /etc/pulse/daemon.conf

uncomment "; flat-volumes=yes"

and change value to no...

reboot...

it work for me...

Regards..

BTW im using FC12, Songbird, and PulseAudio.