If the input AudioFormat changes but the out_audio_format doesn't
change (e.g. because there is a fixed "format" setting in this
"audio_output" section), the ConvertFilter needs to be reconfigured.
This didn't happen, resulting in awful static noise after changing
songs.
This method is used by DecoderControl::IsCurrentSong(), which is used
by the player thread to check whether the current decoder instance can
be reused to seek. When switching to another song in the same CUE
sheet, previously DetachedSong::IsSame() returned true, and thus the
old decoder instance was used for the new song, not considering the
new end_time. This led to the old decoder quickly quitting.
This way, we have four periods instead of the default of two. With
only two periods, we don't get woken up often enough, and we
frequently encounter buffer overruns. With four periods, we have more
time to breathe, and the buffer overruns magically disappear.
The byte order of DSD_U32 was wrong from the start. The oldest bits
must be in the MSB, not in the LSB, according to
snd_pcm_format_descriptions in alsa-lib.
DSD_U32 packs four bytes instead of one large "sample", thus the
sample rate is one quarter of the input sample rate. This fixes a
rather critical DSD_U32 playback problem.
Changed AlsaMixerPlugin to use the get and set normalized functions from volume_mapping of alsa-utils/alsamixer
Changed volume_mapping set volume to be for all channels and not per channel
added volume_mapping files to Makefile.am
Without this, the pipe would run empty very often, which may result in
an xrun if the roundtrip to the PlayerThread and back takes too long.
By waking up the PlayerThread before the pipe runs empty, we make MPD
much more latency tolerant, which is a major optimization.
The user unit omits the "ProtectKernelModules" setting which fails
with modular kernels:
Failed at step CAPABILITIES spawning /usr/bin/mpd: Operation not permitted
It is unfortunate that systemd (version 232) is unable to reduce its
own capabilities, because this requires us to split system and user
units.
https://bugs.musicpd.org/view.php?id=4608
This commit changes a minor queue priority design to something which
makes a little bit more sense.
Previously, a song that had already been played would only be
re-enqueued if its priority had just been raised above the current
song's. This means that if it was already above, it was not
re-enqueued. That is a surprising behavior, because users expect a
song to be played when its priority is raised.
Now the song is always re-enqueued if its priority is raised (and
above the current song's - no matter if it has already been above
before).
https://bugs.musicpd.org/view.php?id=4592
Max Kellermann