Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Volume changes on disabled outputs with ALSA #189

Closed
MiM-TMassey opened this issue Jan 6, 2018 · 3 comments
Closed

Volume changes on disabled outputs with ALSA #189

MiM-TMassey opened this issue Jan 6, 2018 · 3 comments

Comments

@MiM-TMassey
Copy link

Hello!

mpd 0.19.21 on Raspbian stretch on Raspberry Pi 3

I have MPD configured for multiple outputs. When I adjust the volume, I want all outputs to adjust, whether they're enabled or disabled. So when I then later enable the previously-disabled output, its output will be at the current volume level.

This works just fine with PulseAudio: Enable output 1 and 2; set volume to, say, 50; disable output 2; adjust volume to, say, 10; enable output 2 and it will play quietly. Works either way: enable output 1 and 2; set volume to, say 10; disable output 1; adjust volume to, say, 50; enable output 1 and it will play "loudly". In fact, this has worked this way from the beginning for me: I've always used PulseAudio for this system.

However, I'm rebuilding the system, and I'm tired of the out-of-sync sound from PA. So I decided to try using ALSA directly. The volume control does not work with ALSA. If I do the same process, the volumes will be out of sync. For example: Enable output 1 and 2; set volume to, say, 50; disable output #2; adjust volume to, say, 10; enable output #2 and it will play "loudly" (at the previous volume 50!).

This is a real problem: if I start a client, the first thing I do is set the volume (usually to a nice, quiet level) before I press play, then set my outputs, then start playing. However, if I wander to a new area of the house and enable an output, there is a very real chance I'm going to get blasted because that output was disabled when I adjusted the volume and the previous listener was listening at a higher level level -- sometimes much higher! :) It doesn't help that when MPD starts it seems to put all of the outputs at 100% volume...

Am I missing something? I'm not sure why PA and ALSA would work differently in this way, and it seems to me that the PA method is the one that makes more sense. It certainly gives me the most consistent results without unexpected surprises!

My mpd.conf is as simple as I can make it right now:

music_directory "/data/mpd/music"
playlist_directory "/data/mpd/playlists"
db_file "/data/mpd/database"
user "mpd"
bind_to_address "any"
audio_output {
type "alsa"
name "A - Living Room"
device "hw:1,0"
mixer_type "software"
buffer_time "50000"
period_time "5000"
}
audio_output {
type "alsa"
name "Master Bedroom"
device "hw:2,0"
mixer_type "software"
buffer_time "50000"
period_time "5000"
}
samplerate_converter "Best Sinc Interpolator"

To use PA, I just change out the audio_outputs for these:
audio_output {
type "pulse"
name "P - Living Room"
sink "alsa_output.usb-C-Media_INC._USB_Sound_Device-00.analog-stereo"
}
audio_output {
type "pulse"
name "Master Bedroom"
sink "alsa_output.usb-C-Media_INC._USB_Sound_Device-00.analog-stereo.2"
}

(I also have to modify /usr/share/pulseaudio/alsa-mixer/paths/analog-output.conf.common to change [Element PCM] / volume = ignore)

Thank you very much for any information you can provide!

Tim Massey

@MaxKellermann
Copy link
Member

MaxKellermann commented Jan 6, 2018

Your version is ancient and unsupported.

@MiM-TMassey
Copy link
Author

MiM-TMassey commented Jan 7, 2018

I have compiled and updated to 0.20.15, and it does exactly the same thing.

mpd@raspberrypi:~$ mpc version
mpd version: 0.20.0
mpd@raspberrypi:~$ mpd -V
Music Player Daemon 0.20.15

I have found that strange volume information seems to be made available to the client as well as a result of this. When I have two outputs with different volumes, MPC shows the average of the two volumes as the current volume -- even though neither zone is playing at that volume.

I've reproduced this completely using mpc. Here is the result:

mpd@raspberrypi:~$ mpc enable only 1
Output 1 (A - Living Room) is enabled
Output 2 (Master Bedroom) is disabled
mpd@raspberrypi:~$ mpc enable 2
Output 1 (A - Living Room) is enabled
Output 2 (Master Bedroom) is enabled
mpd@raspberrypi:~$ mpc volume 80
Jimi Hendrix - All Along the Watchtower
[playing] #2/2485   2:47/4:01 (69%)
volume: 80%   repeat: on    random: off   single: off   consume: off

Both outputs are playing with the same loud volume, as expected.

mpd@raspberrypi:~$ mpc disable 1
Output 1 (A - Living Room) is disabled
Output 2 (Master Bedroom) is enabled
mpd@raspberrypi:~$ mpc volume 10
Jimi Hendrix - All Along the Watchtower
[playing] #2/2485   2:59/4:01 (74%)
volume: 10%   repeat: on    random: off   single: off   consume: off

One zone is off, and the other is now playing very quietly, as expected.

mpd@raspberrypi:~$ mpc enable 1
Output 1 (A - Living Room) is enabled
Output 2 (Master Bedroom) is enabled

One zone is playing loudly, one zone is playing quietly, not as expected.

mpd@raspberrypi:~$ mpc
Jimi Hendrix - All Along the Watchtower
[playing] #2/2485   3:09/4:01 (78%)
volume: 45%   repeat: on    random: off   single: off   consume: off
mpd@raspberrypi:~$

The volume the client shows is exactly halfway between the two zones. Also not as expected.

As a further test, if I do an "mpc volume 45" (using the same number shown above), both zones change volume levels -- this confirms neither are actually at 45...

And all of this is completely different from how MPD works when using PulseAudio. PA works like I'd expect: whatever adjustments are made to volume are made to each and every output whether it's enabled or disabled, such that when it is re-enabled it's at the expected volume.

Again, please let me know what questions you may have.

Tim Massey

@ostrosablin
Copy link
Contributor

ostrosablin commented Mar 26, 2022

Since #1423 is now resolved, this means current issue should be properly fixed now, too, since they appear to be identical.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants