Hi,
I made a clean install of Fedora 12, and pulseaudio seems to be behaving completely different. Any mixer control I have (master, pcm, front ,,,) affects the pulse volume slider (looking at pavucontrol). In the past, pulse only controlled PCM, I guess.
But the worst point is that there is no more application volume memory. All applications when launched are at full volume, and this is really annoying ...
Is this a kind of new feature? Is it configurable?
On Sun, Nov 29, 2009 at 3:58 PM, Paulo Cavalcanti promac@gmail.com wrote:
Hi,
I made a clean install of Fedora 12, and pulseaudio seems to be behaving completely different. Any mixer control I have (master, pcm, front ,,,) affects the pulse volume slider (looking at pavucontrol). In the past, pulse only controlled PCM, I guess.
This is a feature, not a bug.
But the worst point is that there is no more application volume memory. All applications when launched are at full volume, and this is really annoying ...
This sounds like a bug.... (works for me though)
On Sun, Nov 29, 2009 at 1:01 PM, drago01 drago01@gmail.com wrote:
On Sun, Nov 29, 2009 at 3:58 PM, Paulo Cavalcanti promac@gmail.com wrote:
Hi,
I made a clean install of Fedora 12, and pulseaudio seems to be behaving completely different. Any mixer control I have (master, pcm, front ,,,) affects the pulse volume slider (looking at pavucontrol). In the past, pulse only controlled PCM, I guess.
This is a feature, not a bug.
But the worst point is that there is no more application volume memory. All applications when launched are at full volume, and this is really annoying ...
This sounds like a bug.... (works for me though)
I have two sound cards installed: one onboard and another PCI.
The PCI, the one I do no use very much, works fine. The onboard is the one which does not save the volumes. Every time I call an application its master and pcm volume go to the maximum (I see the sliders going to the top in alsamixer).
I have two sound cards installed: one onboard and another PCI.
The PCI, the one I do no use very much, works fine. The onboard is the one which does not save the volumes. Every time I call an application its master and pcm volume go to the maximum (I see the sliders going to the top in alsamixer).
This has been addressed by the PulseAudio creator. You can read more about it here, see the "PCM is always 100%":
http://pulseaudio.org/wiki/PulseAudioStoleMyVolumes
In my lay explanation, Pulse manages the application volumes behind the scenes. It still remembers their values, but it doesn't use Alsamixer to set them. It tries to use the full volume range of the hardware (for better volume scaling), so it keeps every other software linux volume control at full volume, and scales itself internally.
Otherwise, ALSA would say "you can only use the lower 50% of the sound range of this device". (PCM at 50%). Now Pulse decides internally what volume level is best.
On Sun, Nov 29, 2009 at 2:26 PM, Jud Craft craftjml@gmail.com wrote:
I have two sound cards installed: one onboard and another PCI.
The PCI, the one I do no use very much, works fine. The onboard is the one which does not save the volumes. Every time I call an
application
its master and pcm volume go to the maximum (I see the sliders going to
the
top in alsamixer).
This has been addressed by the PulseAudio creator. You can read more about it here, see the "PCM is always 100%":
http://pulseaudio.org/wiki/PulseAudioStoleMyVolumes
In my lay explanation, Pulse manages the application volumes behind the scenes. It still remembers their values, but it doesn't use Alsamixer to set them. It tries to use the full volume range of the hardware (for better volume scaling), so it keeps every other software linux volume control at full volume, and scales itself internally.
Otherwise, ALSA would say "you can only use the lower 50% of the sound range of this device". (PCM at 50%). Now Pulse decides internally what volume level is best.
Thanks for the explanation.
At least 3 applications are not restoring the volumes:
xmms, mplayer and audacious.
The solution is using the alsa plugin, and not the pulse plugin in these cases.
Some others work fine, such as rhythmbox, amarok, vlc, and kradio4.
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.
The solution is using the alsa plugin, and not the pulse plugin in these cases.
Some others work fine, such as rhythmbox, amarok, vlc, and kradio4.
Michal
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).
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.
Index: audacious-plugins-fedora-2.1/src/pulse_audio/pulse_audio.c =================================================================== --- audacious-plugins-fedora-2.1.orig/src/pulse_audio/pulse_audio.c +++ audacious-plugins-fedora-2.1/src/pulse_audio/pulse_audio.c @@ -666,7 +666,7 @@ static int pulse_open(AFormat fmt, int r pa_stream_set_write_callback(stream, stream_request_cb, NULL); pa_stream_set_latency_update_callback(stream, stream_latency_update_cb, NULL);
- if (pa_stream_connect_playback(stream, NULL, NULL, PA_STREAM_INTERPOLATE_TIMING|PA_STREAM_AUTO_TIMING_UPDATE, &volume, NULL) < 0) { + if (pa_stream_connect_playback(stream, NULL, NULL, PA_STREAM_INTERPOLATE_TIMING|PA_STREAM_AUTO_TIMING_UPDATE, NULL, NULL) < 0) { AUDDBG("Failed to connect stream: %s", pa_strerror(pa_context_errno(context))); goto unlock_and_fail; } @@ -715,6 +715,7 @@ static int pulse_open(AFormat fmt, int r }
pa_operation_unref(o); +#if 0 /* set initial volume */ if (!(o = pa_context_set_sink_input_volume(context, pa_stream_get_index(stream), &volume, NULL, NULL))) { g_warning("pa_context_set_sink_input_volume() failed: %s", pa_strerror(pa_context_errno(context))); @@ -725,6 +726,7 @@ static int pulse_open(AFormat fmt, int r pa_threaded_mainloop_wait(mainloop); } pa_operation_unref(o); +#endif
do_trigger = 0; written = 0;
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.
On Mon, 30 Nov 2009 10:43:10 +0000, Bastien wrote:
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.
Which is exactly my fix that went into Audacious 2.2 before: http://cvs.fedoraproject.org/viewvc/devel/audacious-plugins/audacious-plugin...
On Mon, Nov 30, 2009 at 11:36:01AM +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.
Mplayer needs similiar patch: http://lists.mplayerhq.hu/pipermail/mplayer-users/2009-October/077999.html
On Mon, Nov 30, 2009 at 8:36 AM, Michal Schmidt mschmidt@redhat.com 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.
Index: audacious-plugins-fedora-2.1/src/pulse_audio/pulse_audio.c
--- audacious-plugins-fedora-2.1.orig/src/pulse_audio/pulse_audio.c +++ audacious-plugins-fedora-2.1/src/pulse_audio/pulse_audio.c @@ -666,7 +666,7 @@ static int pulse_open(AFormat fmt, int r pa_stream_set_write_callback(stream, stream_request_cb, NULL); pa_stream_set_latency_update_callback(stream, stream_latency_update_cb, NULL);
- if (pa_stream_connect_playback(stream, NULL, NULL,
PA_STREAM_INTERPOLATE_TIMING|PA_STREAM_AUTO_TIMING_UPDATE, &volume, NULL) < 0) {
- if (pa_stream_connect_playback(stream, NULL, NULL,
PA_STREAM_INTERPOLATE_TIMING|PA_STREAM_AUTO_TIMING_UPDATE, NULL, NULL) < 0) { AUDDBG("Failed to connect stream: %s", pa_strerror(pa_context_errno(context))); goto unlock_and_fail; } @@ -715,6 +715,7 @@ static int pulse_open(AFormat fmt, int r }
pa_operation_unref(o);+#if 0 /* set initial volume */ if (!(o = pa_context_set_sink_input_volume(context, pa_stream_get_index(stream), &volume, NULL, NULL))) { g_warning("pa_context_set_sink_input_volume() failed: %s", pa_strerror(pa_context_errno(context))); @@ -725,6 +726,7 @@ static int pulse_open(AFormat fmt, int r pa_threaded_mainloop_wait(mainloop); } pa_operation_unref(o); +#endif
do_trigger = 0; written = 0;
Your patch almost worked. Audacious starts at the right volume level. However, when audacious volume slider is hit for the first time, the volume goes to the maximum again.
On Tue, 1 Dec 2009 08:34:29 -0200, Paulo wrote:
On Mon, Nov 30, 2009 at 8:36 AM, Michal Schmidt wrote:
[patch]
Your patch almost worked. Audacious starts at the right volume level. However, when audacious volume slider is hit for the first time, the volume goes to the maximum again.
I've explained that earlier in the thread.
Audacious' volume slider does not reflect volume level changes made with external tools. Only with Audacious 2.2 that will become possible. [That also means that when you start Audacious, it does not know what volume level to show with its volume slider as it hasn't connected with Pulse Audio yet.]
Paulo Cavalcanti wrote:
But the worst point is that there is no more application volume memory. All applications when launched are at full volume, and this is really annoying ...
Looks like the "flat volumes" "feature": https://www.redhat.com/archives/fedora-devel-list/2009-June/msg01810.html
Kevin Kofler
On Sun, 29.11.09 12:58, Paulo Cavalcanti (promac@gmail.com) wrote:
Hi,
I made a clean install of Fedora 12, and pulseaudio seems to be behaving completely different. Any mixer control I have (master, pcm, front ,,,) affects the pulse volume slider (looking at pavucontrol). In the past, pulse only controlled PCM, I guess.
http://pulseaudio.org/wiki/PulseAudioStoleMyVolumes
But the worst point is that there is no more application volume memory. All applications when launched are at full volume, and this is really annoying ...
That is not true, unless you reconfigured PA in some way...
Lennart
On Wed, Dec 2, 2009 at 10:43 AM, Lennart Poettering mzerqung@0pointer.dewrote:
On Sun, 29.11.09 12:58, Paulo Cavalcanti (promac@gmail.com) wrote:
Hi,
I made a clean install of Fedora 12, and pulseaudio seems to be behaving completely different. Any mixer control I have (master, pcm, front ,,,) affects the pulse volume slider (looking at pavucontrol). In the past, pulse only controlled PCM, I guess.
http://pulseaudio.org/wiki/PulseAudioStoleMyVolumes
But the worst point is that there is no more application volume memory. All applications when launched are at full volume, and this is really annoying ...
That is not true, unless you reconfigured PA in some way...
You are right. This is true for some applications only, and I found so far three applications needing to be fixed:
xmms, audacious and mplayer.
I installed audacious 2.2 and it is behaving much better.
xmms-pulse plugin was written by you, but I do not know if you are willing to patch xmms.
mplayer will be fixed eventually.
Now that I understand what you have done, it seems to be a good idea indeed.
On Wed, Dec 2, 2009 at 11:18 AM, Paulo Cavalcanti promac@gmail.com wrote:
On Wed, Dec 2, 2009 at 10:43 AM, Lennart Poettering mzerqung@0pointer.dewrote:
On Sun, 29.11.09 12:58, Paulo Cavalcanti (promac@gmail.com) wrote:
Hi,
I made a clean install of Fedora 12, and pulseaudio seems to be behaving completely different. Any mixer control I have (master, pcm, front ,,,) affects the pulse volume slider (looking at pavucontrol). In the past, pulse
only
controlled PCM, I guess.
http://pulseaudio.org/wiki/PulseAudioStoleMyVolumes
But the worst point is that there is no more application volume memory. All applications when launched are at full volume, and this is really annoying ...
That is not true, unless you reconfigured PA in some way...
You are right. This is true for some applications only, and I found so far three applications needing to be fixed:
xmms, audacious and mplayer.
I installed audacious 2.2 and it is behaving much better.
xmms-pulse plugin was written by you, but I do not know if you are willing to patch xmms.
mplayer will be fixed eventually.
Now that I understand what you have done, it seems to be a good idea indeed.
mplayer and audacious have been fixed upstream.
Regarding xmms, I patched it myself:
https://bugzilla.redhat.com/show_bug.cgi?id=559777
I hope the patch is applied ...
-
Bastien Nocera -
drago01 -
Jud Craft -
Kevin Kofler -
Lennart Poettering -
Michael Schwendt -
Michal Schmidt -
Paulo Cavalcanti -
Tomasz Torcz