This attribute shall be used only for IsInside() to make this safe
against a race condition described in #188:
> There is no requirement on the implementation that the ID of the
> created thread be available before the newly created thread starts
> executing.
http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_create.html):
This means that on some pthread implementations (e.g. Haiku), the
assert(thread.IsInside()) could fail.
Closes#188
This completes the bug fix commit
2065e3290452377b2931f3129b230c8cc536cbc8; if we clear "queued" then we
must clear "queued_song" as well, or another variant of the assertion
fails.
In current Android SDK releases, Ant support was removed. Move the
necessary build steps from the former Ant build system to our Makefile,
and call the required build tools from the Android SDK (aapt and dx),
Java SDK (javac) and Info-ZIP (zip) directly.
[mk: copied from Felix's commit
e52b906dba971a1173f9e8f83d32b52ee9f89af3 in the XCSoar project)
Supporting GCC 4.9 is becoming cumbersome as we refactor more code to
C++14.
This shouldn't be a problem for anybody, because Debian Stable
(Stretch) has version 6.3, and Ubuntu LTS (Xenial) has version 5.3.
Fixes deadlock because FileInputStream::Read() unlocks the mutex
(which was not locked) and then locks it, keeping it locked. This can
result in a deadlock. This happens because the archive and the file
mutex are different.
If a directory is a mount point, omit the "directory: " as well.
This bug is years old, but has become more visible now that mount
points are persistent in the state file.
These attributes are printed in the "outputs" response, and the new
command "outputset" allows setting new values.
No attributes are currently implemented.
If `SimpleDatabase::Visit` is called on a database that contains a mounted directry the URIs of the elements passed to the callbacks are not prefixed by the mountpoint path. This leads to lsinfo and add not working because they use the wrong URI. This pull request is using the `WalkMount` helper function to create prefixed versions of `VisitDirectory`, `VisitSong` and `VisitPlaylist` to add the correct prefix to the parameters of the callback functions.
[mk: the following text was copied from
https://github.com/MusicPlayerDaemon/MPD/pull/167]
For certain format (hi-res files) and normal buffer size hardware, The
hardware may at once consume most of the buffers. However, in Delay()
function, MPD is supposed to wait for 25 ms after the next try. it
will create a hiccup. The negative impact is much major than
increasing the latency.
I understand larger buffers come at a price. That's why in my earlier
commit last year I significantly reduced it. However, the buffer size
in CoreAudio is set according to the hardware, which is super small
latency. For instance, the system audio of 2015 generation of macbook
pro has maximum buffer size of 4096 samples, which is just 0.09s for
44.1k framerate, or 0.04s for 96k frames --- . compare to the 0.5 sec
latency alsa plugin has, even if we quadruple it, it's still super
tiny.
libupnp 1.6.24 added a few badly designed macros which break the MPD
build:
8177a4195a/
To work around this, we disable our emulation functions (from
714011c81e) on this libupnp version.
Closes#163
Without the flush, ReadPage() may not return any data, or not all
data. This may result in incomplete ddata the new "header" page,
corrupting streams with some encoders such as Vorbis.
Fixes#145
Don't require a quality or bitrate setting. If nothing is set, don't
fail startup - just go with a good default. A quality setting of 3 is
what "oggenc" defaults to as well.
InputStream::Read() and InputStream::Seek() are called with the mutex
locked. That means the implementation must not block, or unlock the
mutex before calling into blocking code.
Previously, a slow CD drive could stall the whole MPD process,
including the main thread, due to this problem.
Closes#149
Turns out that using CP_ACP is a lousy idea, because only very few
Unicode characters can be represented by it. Instead, switch to UTF-8
(which every sane person on other operating system already uses).
Closes#102
Our previous use of Queue::SwapOrders() could cause surprising
results:
- sometimes, the old "current" song would be played again (if the
newly selected song had not been played already)
- sometimes, the old "current" song would not be played again (if the
newly selected song had already been played)
This is inconsistent, because it should not depend on whether the
newly selected song had already been played.
So instead of Queue::SwapOrders() we now use Queue::MoveOrderAfter()
and Queue::MoveOrderBefore(), which is more expensive, but also more
consistent. It attempts to retain as much from the previous order
list as possible, and only moves the newly selected song around.
If an early exception gets caught (e.g. from
AllocatedPath::FromUTF8Throw()) before
DecoderControl::CommandFinishedLocked() is called, the decoder thread
would go in an endless loop, because DecoderCommand::START is still
set.
Closes#118
Our IcuCaseFold() fallback using strxfrm() is not actually case
insensitive. This commit fixes the problem by switching to
strcasecmp(). That function is not guaranteed to support UTF-8, but
it's the best we can do in this sparse situation.
Closes#111
RoarAudio's sndio emulation has been a source for annoyances. First,
their headers turned out to be broken with C++, due to their use of
the "new" keyword. Then they used a preprocessor macro to rename
"sio_hdl" to something else, effectively disallowing the use of
forward declarations. Enough is enough, and I'm removing support for
it.
RoarAudio users should better use the RoarAudio output plugin.
This commit is similar to 788e3b31e1,
and removes more "pure" attributes which were placed on functions that
could throw exceptions, which is illegal according to clang's
understanding of the attribute (but not according to GCC's). GitHub
issue #58 was most likely about StorageDirectoryReader::GetInfo() and
Storage::GetInfo(), which still had "pure" attributes.
Closes#58
Fixes build failure on OS X, closes#44. With the other plugins,
that's not critical, because those use the AudioOutputWrapper, which
hides this problem.
The "pure" and "const" attributes are not so well-defined, and a
recent clang version implements an optimization which pushes the
definition's boundary beyond what I believed it was. clang now
assumes that functions declared "pure" cannot throw exceptions, even
if they lack the "noexcept" specification.
When compiled with this new clang version, MPD will crash randomly if
an exception happens to get thrown by such as "pure" function
(https://github.com/MusicPlayerDaemon/MPD/issues/41).
This commit removes all such misplaced "pure" and "const" attributes,
closing #41.
An ino_t is usually a 64 bit integer, and some file systems (such as
Linux's kernel NFS client) really uses the upper 32 bit. This can
lead to false positives in the directory loop detection in
FindAncestorLoop(). Increasing these two attributes (in
StorageFileInfo and Directory) to 64 bit adds little overhead, but
makes the check a lot safer.
The TAG_MODIFIED handler (i.e. playlist::TagModified()) works only if
the modified song is the current song - something that is not updated
until SYNC_WITH_PLAYER is finished. This fixes tag updates right
after a new song is started.
https://bugs.musicpd.org/view.php?id=4656 describes a crash due to
division by zero because frame.samples==0. This should never happen,
but apparently can happen after seeking. The best we can do is to
just ignore this frame.
Fixes another buffer overflow: if the stream has a very long title or
URL, resulting in a metadata string of more than 2 kB, icy_string[0]
is a negative value, which gets casted to size_t - ouch!
https://bugs.musicpd.org/view.php?id=4652
Use SND_PCM_NONBLOCK, and perform all snd_pcm_writei() calls in the
IOThread. Use a lockless queue to copy data from the OutputThread to
the IOThread.
This rather major change aims to improve MPD's internal latency. All
waits are now under MPD's control, instead of blocking inside
libasound2.
As a side effect, an output's filter is now decoupled from the actual
device I/O, which solves a major latency problem with the conversion
filter on slow CPUs and small period buffers. See:
https://bugs.musicpd.org/view.php?id=3900
When rpc_reconnect_requeue() gets called from inside nfs_service(),
the NfsInputStream can stall completely because the old socket has
been unregistered from epoll automatically, but the new one has never
been registered. Therefore, nfs_service() will never be called again.
This kludge attempts to detect this condition by checking
nfs_which_events()==POLLOUT.
https://bugs.musicpd.org/view.php?id=4081
If the base class is not accessible, the "catching" the base class
won't work. This caused the fatal error:
terminate called after throwing an instance of 'LibmpdclientError'
Each close/open cycle resets the Filter's state, because a new Filter
instance is being created. That results in the serials
(replay_gain_serial and other_replay_gain_serial) being out of sync
with the internal ReplayGainFilter state.
So instead of initializing those serials once, we need to initialize
them each time we create new ReplayGainFilter instances, i.e. in
OpenFilter().
https://bugs.musicpd.org/view.php?id=4632
Previously, there was no special code to convert stereo to
multi-channel. The generic solution for this was to convert to mono,
and then copy the result to all channels. That's a pretty bad
solution, but at least something which always renders audio. MPD does
something, instead of failing.
Now that MPD has proper support for multi-channel (by defining the
channel order), we can do better than that. It is a (somewhat) common
case to play back stereo music on a DAC which can only do
multi-channel. The best approach here is to copy the stereo channels
to front-left and front-right, and apply the "silence" pattern to all
other channels.
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