We're not interested in the *.class files, we run javac only to
generate the JNI header. By using @PRIVATE_DIR@, it gets stored to a
directory we can ignore, and not into the source tree.
Turns out Meson disables ccache auto-detection when a cross-file is
used. To use ccache, the ccache prefix must be expressed in an array
instead of a single string with spaces.
It is not possible to prepare an ALSA device when it is is state
SND_PCM_STATE_OPEN; it is necessary to set the hardware parameters
first.
This pedantic commit corrects that error. Note that in practice
this code path cannot be encountered because MPD always sets the
hardware parameters before attempting to start playback.
It is possible that an underrun may occur in the ALSA output
device while MPD is draining its own internal buffer. If this
happens then MPD stops playback, reporting the error EPIPE.
This commit attempts to recover the ALSA device instead of
stopping playback, so that the drain can complete and the next
song in the play queue is played.
This reverts commit 94b5b9f370. It was
not necessary for branch v0.23.x because there, Break() is
thread-safe; this was only changed later by commit
a3b32819b1
snd_pcm_poll_descriptors_revents() may return any error code; the
ALSA docs do not constrain the permitted values. A 'hw' device
will only ever return an error if the pfd array passed in is
invalid (-EINVAL), but other I/O plugins may return arbitary
errors. For example a network-based device may return -EPIPE etc.
The resulting exception thrown by
AlsaNonBlockPcm::DispatchSockets() must be caught to prevent the
mpd process from being aborted.
Some ALSA capture devices can have very large buffers, holding 10
seconds or more audio. Using the maximum buffer size with such
devices leads to unacceptably large, and unnecessary, latency.
Also, some ALSA drivers (e.g. HDA Intel PCH) report an invalid
maximum period size, and the period size that mpd calculates from
the maximum buffer size results in "Invalid argument" error when
applying the hw_params. Note that the "default" capture device on
many cards includes the "dsnoop" plugin which imposes a buffer
size of 16384 frames, so that "alsa://" works OK but
"alsa://plughw" or "alsa://hw" both fail.
Limit the maximum buffer time for ALSA input devices to a more useable
2 seconds, thereby avoiding both the above problems.
Max Kellermann