What version of rhythmbox are you using?  Do you have crossfading enabled?

Can you provide some actual concrete steps to reproduce the problem?  I don't really know what your description means or what the problem actually is.

So this is about the internal Rhythmbox volume control, that has a small slider in the top right corner.

Happens with both rhythmbox 0.12 and 0.12.2
Both with crossfading enabled and disabled.

Test setup:
Jaunty + Linux Kernel 2.6.30 + Alsa 1.0.19 + PA 0.9.15

I guess Karmic or Fedora 11 should be a good test setup also.

What happens with Pulse 0.9.14 (default Jaunty behavior):
1) You set the speaker volume to 30%
2) You set the volume in RB to 100%
Sound output is 30%

What happens with Pulse 0.9.15:
1) You set the speaker volume to 30%
2) You set the volume in RB to 100%
Sound output is 100%

This actually sounds like an API-break in Pulseaudio.
That, or you're not using the API in the correct way.

To me, that sounds like exactly what the flat volume feature is supposed to do.

Rhythmbox doesn't use the pulseaudio API, and when using playbin2, all it does is set the playbin2 volume parameter.

It says like this in the RB 0.12 release notes:
* If using pulseaudio, control the output volume using the PA stream volume

Well it's a big difference from how it works with PA 0.9.14, regression imho.
If you intend to keep this behaviour, there are two major problems though:

1) Doesn't read the correct application volume at startup. So the slider could be at 100% while the volume is at 20%, touching the slider will suddenly put the volume at 100%.

2) 1% volume on the slider == 58% volume in pulseaudio. There's some problem with the logaritmic vs linear values somewhere I'd guess.

Of cource I can report those as separate bugs when we are finished with this discussion.

(In reply to comment #4)
> It says like this in the RB 0.12 release notes:
> * If using pulseaudio, control the output volume using the PA stream volume
> 
> Well it's a big difference from how it works with PA 0.9.14, regression imho.
> If you intend to keep this behaviour, there are two major problems though:

We don't even have a choice in the matter.  playbin2 uses the stream volume automatically.

> 1) Doesn't read the correct application volume at startup. So the slider could
> be at 100% while the volume is at 20%, touching the slider will suddenly put
> the volume at 100%.

I suppose we should read the volume from the stream once it's available.  I'll look into that.

> 2) 1% volume on the slider == 58% volume in pulseaudio. There's some problem
> with the logaritmic vs linear values somewhere I'd guess.

This sounds something like bug 571610.

(In reply to comment #5)
> 
> > 1) Doesn't read the correct application volume at startup. So the slider could
> > be at 100% while the volume is at 20%, touching the slider will suddenly put
> > the volume at 100%.
> 
> I suppose we should read the volume from the stream once it's available.  I'll
> look into that.

So, with pulseaudio, the correct thing to do is to let it remember the application volume setting, which it restores and properly applies relative to the reference volume (or something like that anyway).  If we restore it ourselves, pulseaudio can't distinguish that from a user volume adjustment, so it (apparently) overrides the reference volume.

With anything else, the correct thing to do is to restore the last volume level that the user set.

Then there's the question of what to do if the user adjusts the volume before playing anything.

fixed in commit 65f1f82ef9fda2f878be45aeef5ab26dbcf0beab

Now we only restore the previous volume when not using pulseaudio.  Everything else now works correctly as far as I can tell.

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

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

This fix only works for me with crossfade enabled.  I'm using pulseaudio on F11.

If crossfade is not enabled, then every time a new track is selected (on initial start, with Previous, Next, or double-clicking on a track in the window), volume reduces to 40% of the previous value.  From 100% (full volume) to 40% to 16% to 6(.4)%, etc.  When rhythmbox advances to the next track in the playlist after a track finishes, all is normal, however.

With crossfading enabled, volume stays the same.

I can confirm this on Ubuntu. With crossfading active it works correctly, without the master volume is still changed.

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

Yeah, why is this resolved? I have the issue in current karmic (rhythmbox 0.12.3, pulseaudio 1:0.9.16~test5-0ubuntu2). I have it with or without cross-fading enabled.

There was also a GStreamer component to the problem.  You probably don't have a version of GStreamer that includes the fix.

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

"So, with pulseaudio, the correct thing to do is to let it remember the
application volume setting, which it restores and properly applies relative to
the reference volume (or something like that anyway)."

But this is weird, because the reference volume gets restored when rhythmbox quits, but the application volume setting gets remembered as "x dB compared to reference volume."

This happens to me and is reproducible:
1) Set reference volume to -20 dB with rhythmbox not running.
2) Start rhythmbox and start playing a file.  Raise rhythmbox volume to 100%, which sets the pulseaudio main volume to 0 dB.
3) Quit rhythmbox; the pulseaudio reference volume is restored to -20 dB.
4) Change the pulseaudio reference volume to 0 dB, increasing it by 20 dB.
4) Start rhythmbox again and start playing.  The pulseaudio main volume gets set to 0 dB (old application level) + 20 dB (change in pulseaudio main volume since last run) = 20 dB, which is over 100% and results in clipping and other nasty stuff.  Can hurt your ears.