On Mon, 2009-11-30 at 11:36 +0100, Michal Schmidt wrote:
Dne Mon, 30 Nov 2009 11:12:38 +0100 Michael Schwendt napsal(a):
> On Mon, 30 Nov 2009 10:38:15 +0100, Michal wrote:
> > Dne Mon, 30 Nov 2009 07:05:28 -0200 Paulo Cavalcanti napsal(a):
> > > Thanks for the explanation.
> > >
> > > At least 3 applications are not restoring the volumes:
> > >
> > > xmms, mplayer and audacious.
> > Interesting. Maybe these programs try to be too clever and force the
> > volume themselves.
> It's not an attempt at being "too clever", but several upstream
> developers feel lost in what they have to do or what they have not to
> do to get something right. Temporarily, Audacious devlopers have
> dropped their "pulse_audio" driver (originally from XMMS) even, since
> they were of the impression that "it didn't work anyway". Ubuntu
> users currently feel punished with Pulse Audio. With a first bunch of
> fixes [for volume issues in Fedora 12 Rawhide, volume decreased for
> every new song], the driver was restored again for Audacious 2.2
> development. With more recent changes in Pulse Audio, it seems, more
> changes are necessary. But Audacious 2.1 cannot reflect external
> volume level changes in its UI anyway. Its volume slider cannot move
> for volume level changes made with external tools. Only the next
> release can do that, and it suffers from new bugs (such as a bug in
> alsa-lib that will require an update in Fedora, too).
Thanks for the explanation. Before I saw your reply, I played with
audacious-plugins and made a kludge to prevent it from forcing 100 %
volume on startup. It probably breaks something else, I haven't really
tested it too much.
Notice that the documentation for pa_stream_connect_playback strongly
recommends passing NULL as volume.
This looks correct, you're never supposed to restore volume yourself
when using PulseAudio.