Previous versions of MPD would, on parameter change, set the PipeWire
volume before clearing the restore_volume flag, causing the call to
short circuit and do nothing. Instead, clear the flag before the call.
Move audio output state check ahead of mixer check and force volume
applying even for disabled software mixed outputs.
This fixes incorrect software mixer volume that used to occur when
volume was changed while output being disabled.
This is easily reproduced with following sequence of commands on
multi-output software mixed MPD setup.
mpc volume 38; mpc disable 3; mpc volume 88; mpc enable 3
On current MPD, following commands would result in output 3 playing at
volume 38, while all other enabled outputs would play at volume
88. Moreover, global volume would display average of outputs real
volumes. In my case, it's 75.
After applying this patch, following commands would produce expected
behavior. All outputs play at expected (88) volume. And volume is
correctly displayed as 88.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/1423
Signed-off-by: Vitaly Ostrosablin tmp6154@yandex.ru
Signed-off-by: Vitaly Ostrosablin <tmp6154@yandex.ru>
Wasapi output plugin won't start playing after being paused
The cause is that the scope guard in the WASAPI work thread
(WasapiOutputPlugin.cxx, function WasapiOutputThread::Work(), in the
while (true) loop) is set up too 'late' in the execution. There is one
condition ("if (data_in_frames >= buffer_size_in_frames)") when it is
hit, the loop will continue without executing the scope guard. This
scope guard is responsible for emptying the buffer again, and if the
buffer is not emptied, the above mentioned condition will stay true.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/1451
This reverts commit 552c30eae4.
It has caused various problems; for example, MPD wasn't able to write
the pid_file (which was already mitigated by commit a4e4217204).
And apparently, the socket file created in the same directory by
mpd.socket disappears when mpd.service (re)creates the directory. I
could not reproduce this problem with 247.3, but maybe this is a bug
in older systemd versions?
Until we figure out why this happens, let's remove the
RuntimeDirectory directive. A future MPD version may be launched as
regular user, not as root, which will eliminate one major problem with
RuntimeDirectory.
Commit 552c30eae caused problems for those people who still had a
"pid_file" setting (even though that is obsolete with systemd),
because now /run/mpd is owned by root:root (our mpd.service has no
User=mpd directive, so systemd starts MPD as root).
To work around this problem, and to be able to keep
RuntimeDirectory=mpd (which solved a problem of other MPD users), the
best compromise seems to just ignore the "pid_file" setting when it is
of no use.
Max Kellermann