Description of problem: Adjusting the speaker balance all the way to the left on a stereo setup seems to a) Reduce sound out of both speakers at the same time. b) Move the balance slider back to the centre over time. Version-Release number of selected component (if applicable): pulseaudio-module-gconf-0.9.21-5.fc13.i686 pulseaudio-module-bluetooth-0.9.21-5.fc13.i686 pulseaudio-gdm-hooks-0.9.21-5.fc13.i686 pulseaudio-0.9.21-5.fc13.i686 pulseaudio-libs-0.9.21-5.fc13.i686 pulseaudio-libs-glib2-0.9.21-5.fc13.i686 gnome-media-2.28.5-2.fc13.i686 gnome-media-libs-2.28.5-2.fc13.i686 pulseaudio-utils-0.9.21-5.fc13.i686 pulseaudio-module-x11-0.9.21-5.fc13.i686 How reproducible: The problem is reproducible every time. Steps to Reproduce: 1. Start gnome-terminal . 2. Run speaker-test . 3. Press Ctrl-Shift-T to get another tab 4. Run alsamixer -D hw:0 . 5. Press Alt-F2. 6. Run gnome-volume-control . 7. In the "Sound Preferences" window select the Output tab. 8. Move the Balance slider all the way to the left. Actual results: Quieter sound comes out of both speakers. alsamixer shows both volumes on the Master mixer are at 61 and both volumes on the PCM mixer are at 100%. Every 12 seconds (or less) the balance slider will take a jump to the centre. Additionally there is a moment of silence every 12 seconds which is not there when playing sound directly to ALSA from speaker-test. Expected results: Sound to only come out of the left speaker. The right channel of both Master and PCM to be 0 in alsamixer. The balance to stay where it is put until the volume slider is manually adjusted. No silence ever 12 seconds. Additional info: Other strange balance behaviour is seen in other distributions: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/532095 .
a) is expected. I mean, if you blast at full volume from one speaker it is of course less loud then if you'd do it with two speakers! Wat did you expect? b) sounds as if some app is feeding back volume changes to PA. To track this down, please run "pulseaudio -vvvvv" in a terminal (set autospawn=no in ~/.pulse/client.conf and run pulseaudio -k first to make sure you can run it like that). This will then write a lot of debug output to the terminal, including a line each time a client changes the volume. Do you see any line related to volume changes printed there, whenever the volume goes down one step?
Regarding a): I don't think a) is to be expected... I am saying the following: Steps: When the balance slider is all the way to the left and the overall volume is at 100%: Expected: Sound to ONLY come out of the left speaker at 100%. Actual: Sound comes out of BOTH speakers at 61%. Perhaps the Actual and Expected results in the original comment were not clear about this. Lennart: Can you clarify if you see the "Actual" behaviour too using the steps in the original comment? Further, is this new explanation clearer? Regarding b): I see output like the following: I: sink-input.c: module-stream-restore.id = "sink-input-by-application-name:ALSA plug-in [speaker-test]" I: protocol-native.c: Requested tlength=43690.67 ms, minreq=10922.67 ms D: protocol-native.c: Early requests mode enabled, configuring sink latency to minreq. D: alsa-sink.c: Cutting sleep time for the initial iterations by half. D: alsa-sink.c: Cutting sleep time for the initial iterations by half. D: memblockq.c: memblockq requested: maxlength=4194304, tlength=4194304, base=2, prebuf=3145728, minreq=191982 maxrewind=0 D: memblockq.c: memblockq sanitized: maxlength=4194304, tlength=4194304, base=2, prebuf=3145728, minreq=191982 maxrewind=0 I: protocol-native.c: Final latency 45690.48 ms = 39691.04 ms + 2*1999.81 ms + 1999.82 ms D: alsa-sink.c: Requested volume: 0: 50% 1: 50% D: alsa-sink.c: Got hardware volume: 0: 50% 1: 50% D: alsa-sink.c: Calculated software volume: 0: 100% 1: 100% (accurate-enough=yes) I've also checked and against ALSA without pulseaudio, speaker-test does not change the volume in any fashion. I will attach a full log that can be inspected but the problem should be reproducible every time with the steps in the original comment.
Created attachment 402118 [details] pulseaudio -vvvvv log
Created attachment 402121 [details] pulseaudio -vvvvv log Pulseaudio vvvvv log. Records gnome-volume-control being started, the overall volume being moved to 100%, the balance slider being dragged from centre all the way to the left, gnome-volume-control being exited, speaker-test being run (and every time speaker-test prints new text after initially running the volume increases on both speakers).
This is still here in Fedora 13 final. The issue only occurs when alsa-plugins-pulseaudio is installed - more explicitly when /etc/alsa/pulse-default.conf sets pulse as the default sound card.
Still here in Fedora 14 Alpha updating to 14. Additional information: This seems to affect speaker-test exclusively. Other apps like totem or even aplay don't show this problem.
This is definitely a bug that I'm running into when using audacity. With a left-channel-only stereo clip playing, it's output to both channels when the PA SoundPrefs slider in the center (default); it's played to the left speaker when the slider's moved to the left, and it's mute when moved to the right. Definitely wonky left/right balance behavior. alsa-plugins-pulseaudio-1.0.22-1.fc13.i686 alsa-plugins-pulseaudio-1.0.22-1.fc13.x86_64 pulseaudio-0.9.21-6.fc13.x86_64 pulseaudio-gdm-hooks-0.9.21-6.fc13.x86_64 pulseaudio-libs-0.9.21-6.fc13.i686 pulseaudio-libs-0.9.21-6.fc13.x86_64 pulseaudio-libs-glib2-0.9.21-6.fc13.x86_64 pulseaudio-module-bluetooth-0.9.21-6.fc13.x86_64 wine-pulseaudio-1.3.1-1.fc13.i686
meant to say that a left-channel-only audioclip is played to BOTH speakers when the slider's in the center, or moved all the way to the left (no change in volume). Mute when moved to the right.
Still here on a Fedora 15 Alpha LiveCD (desktop-i386-20110223.05.iso). alsa-plugins-pulseaudio-1.0.24-2.fc15.i686 pulseaudio-0.9.22-3.fc15.i686 pulseaudio-gdm-hooks-0.9.22-3.fc15.i686 pulseaudio-libs-0.9.22-3.fc15.i686 pulseaudio-libs-glib2-0.9.22-3.fc15.i686 pulseaudio-module-bluetooth-0.9.22-3.fc15.i686 pulseaudio-module-gconf-0.9.22-3.fc15.i686 pulseaudio-module-x11-0.9.22-3.fc15.i686 pulseaudio-utils-0.9.22-3.fc15.i686
Fedora 14 x86_64 pulseaudio-0.9.21-7.fc14.x86_64 gnome-media-2.32.0-2.fc14.x86_64 Turning off "flat-volumes" fixed things for me. With "flat-volumes" on it seemed like every app wanted its own balance but no one could agree with one another so it became really wacked with the "center" balance becoming 40% left speaker 60% right. With the option off, the balance slider acts as expected and all apps (rhythmbox, totem, etc) sound correct now.
I'm amazed but Michael is absolutely right - this is due to flat volumes. Running echo "flat-volumes = no" >> /etc/pulse/daemon.conf as root and then doing pulseaudio -k as a regular user stops the problem from happening...
Confirming. I had previous discounted this because I commented out: flat-volumes = yes in daemon.conf and got no improvement. But, apparently it's the default now, since setting it explicitly to 'no' brought back my right speaker. 2.6.35.13-91.fc14.x86_64 pulseaudio-0.9.21-7.fc14.x86_64 Thanks, Michael & Sitsofe.
Still here in Fedora 15 final. It also worth noting that the only thing using pulseaudio has to be speaker-test to see the effect.
Still here in Fedora 17 Beta RC3. Steps to reproduce: 1. Start gnome-terminal . 2. Run speaker-test . 3. Press Ctrl-Shift-T to get another tab 5. Run gnome-control-center sound . 6. In the "Sound" window select the Output tab. 7. Move the Output slider to 100% and the Balance slider all the way to the left. 8. Wait for 20 seconds. Expected results: Balance volume to stay all the way to the left. Actual results: Every time the speaker-test period restarts the volume moves closer to the centre. Additional information: speaker-test must be the only thing playing sound for the effect to be seen. disabling flat volumes stops the problem from occuring. Version information: alsa-lib-1.0.25-3.fc17.i686 kernel-3.3.0-1.fc17.i686 pulseaudio-1.1-8.fc17.i686
I fixed my own in F16 x86_64 I follow this guide, http://fedoraunity.org/Members/fenris02/pulseaudio-fixes-and-workarounds I install pavucontrol then I restart the pulseaudio and problem is fixed now I can hear both it working in youtube,video,music etc..
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Reopening as this happens with Fedora 20/rawhide.
I am not seeing this on F20. Lennart is no longer involved with PA so I'd suggest filing upstream or reassigning to the Rex or Kalev.
CCing Rex and Kalev since they seem to be the de facto PA maintainers these days. (Any reason no-one's taken the package over from Lennart, guys?)
(Still here in Fedora 21)
If anyone is interested in getting to the bottom of this, I'd I'd recommend poking upstream too, probably mailing list: http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss (I personally don't know, it could possibly be this is simply an implementation detail of how flat-volumes works)
My track record with upstream pulseaudio isn't good - last time it took Canonical to fix my pulseaudio issue... By the way I was wrong with regard to Fedora version in my previous comment - it was Fedora 22 (which is why I left the version at rawhide).
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still here in Fedora 23: pulseaudio-module-bluetooth-7.1-1.fc23.x86_64 pulseaudio-libs-glib2-7.1-1.fc23.x86_64 pulseaudio-7.1-1.fc23.x86_64 pulseaudio-module-x11-7.1-1.fc23.x86_64 pulseaudio-gdm-hooks-7.1-1.fc23.x86_64 pulseaudio-libs-7.1-1.fc23.x86_64 pulseaudio-utils-7.1-1.fc23.x86_64
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.