Works around a problem where MPD goes into a busy loop because
snd_pcm_drain() always returns `-EAGAIN` without making any progress
(fixes#425).
This problem was triggered by snd_pcm_drain() after snd_pcm_cancel()
and snd_pcm_prepare(), but without submitting any data with
snd_pcm_writei().
I believe this is a kernel bug: in non-blocking mode, the kernel's
snd_pcm_drain() function returns early. In this mode, it only checks
whether snd_pcm_drain_done() has been called already, but
snd_pcm_drain_done() is never called if no data was submitted.
In blocking mode, the following `for` loop detects this condition, so
snd_pcm_drain_done() is not necessary, but without this extra check,
we get `-EAGAIN` forever.
test/run_storage.cxx depends on EventThread/EventLoop from libevent.a.
Depend on it explicitly. This addresses build failure with
-Dtest=true -Dcurl=disabled -Ddbus=disabled
This fixes a problem which caused a failure with snd_pcm_writei()
because snd_pcm_drain() had already been called in the previous
iteration. This commit makes sure that snd_pcm_drain() is only called
after the final snd_pcm_writei() call.
This fixes discarded samples at the end of playback.
MPD's default is 100ms, which is too long for the real-time I/O
thread. The OutputThread has 100us, but the real-time I/O thread
might have tighter deadlines.
This change has currently no effect (I believe), because nobody uses
timers on the RTIO thread.
If our `ring_buffer` is smaller than the ALSA-PCM buffer (if the
latter has more than the 4 periods we allocate), it can happen that
the start threshold is crossed and ALSA switches to
`SND_PCM_STATE_RUNNING`, but the `ring_buffer` is empty. In this
case, MPDD will generate silence, even though the ALSA-PCM buffer has
enough data. This causes stuttering (#420).
This commit amends an older workaround for a similar problem (commit
e08598e7e2) by adding a snd_pcm_avail()
check, and only generate silence if there is less than one period of
data in the ALSA-PCM buffer.
Fixes#420
The method Cancel() assumes that the `period_buffer` must be empty
when `active==false`, but that is not the case when Play() fails.
Of course the assertion in Cancel() is not 100% correct, but I decided
to rather fix this in LockCaughtError() because the `period_buffer`
should only be accessed from within the RTIO thread, and this is the
only code path where `active` can be set to `false` with a non-empty
`period_buffer`.
Fixes#423
This check was added 9 years ago in commit
4dc25d3908 to work around a dmix bug
which I assume has been fixed long ago.
Removing this fixes another corner case: if draining is requested
before the start threshold is reached, the PCM is still in
SND_PCM_STATE_PREPARED but not yet SND_PCM_STATE_RUNNING, which means
the submitted data will never be played. This corner case is
realistic when playing songs shorter than the ALSA buffer (if the
buffer is very large).
This fixes a corner case which has probably never occurred and
probably never will: if Cancel() is called, and then Play() followed
by Drain(), the plugin should really play that data. However
currently, this never happens, because snd_pcm_prepare() is never
called.
I added this sentence in commit
5271e81ebe, but this was merely
documented the legacy status quo, which has always been undocumented
for old-style filters.
But for new filters, using "==" for sub strings was a surprising
"feature", which I removed in commit
ac0852b4e3.
When `metadata_sent` is `false`, the plugin assumes there is metadata
which must be sent, even if no metadata page was passed to the plugin.
Initializing it to `true` avoids dereferencing this `nullptr`.
Fixes#412
If the output is already open, the `current_chunk` pointer may be
bogus and out of sync with `SharedPipeConsumer::chunk`, leading to an
assertion failure in `SharedPipeConsumer::Consume()`.
Fixes#411
Meson always enables large file support on the compiler command line,
thus config.h doesn't need to be included anymore. We'll remove the
whole `check.h` header soon.
Closes#409
`AVCodecParameters` contains values from the codec detected by
avformat_find_stream_info(), but after avcodec_open2(), a different
codec might be selected with a different `AVSampleFormat`. This leads
to misinterpretation of data returned from FFmpeg, leading to random
noise or silence.
This was observed with FFmpeg 4.0.2 and a TS container file containing
MP2. A mp3-float codec was detected returning `AV_SAMPLE_FMT_FLTP`,
but finally the `mpegaudiodec_fixed.c` was used, returning
`AV_SAMPLE_FMT_S16`.
By using the audio format from `AVCodecContext`, we ensure that MPD
and FFmpeg always agree on the actual audio format in the buffer.
This removes the FFmpeg bug workaround from commit e1b032cbad which I
assume is obsolete after 7 years.
Fixes#380
ensure that valid mixer values are set also when the ALSA driver
does not report a valid dB range ('set_raw' fallback)
correct a bug in which volume is assumed to lie in [0..100]
instead of [0..1]
The protocol documentation says that the difference between `find` and
`search` is that `search` is case insensitive, but that's only half
the truth: `search` also searches for sub strings instead of matching
the whole string. This part is undocumented and unfortunate, but at
this point, we can't change it.
However leaking this surprising behavior to the new filter expressions
was a bad idea; the "==" operator should never match substrings. For
people who need that, we should add a new operator.
Meson 0.47.1 suffers from a bug which breaks linking the MPD
executable because the `-lpthread` flag is not propagated from our
`thread.a`.
See https://github.com/mesonbuild/meson/pull/3895Closes#403
Thanks to C++14, we can declare and fill variables inside `constexpr`
functions. This means me can stop make assumptions on the `struct`
layouts without losing `constexpr`.
Closes#393
Bugs in libroar which broke the MPD build have been annoying me for
quite some time, and the newest bug has now hit my main build machine:
https://github.com/MusicPlayerDaemon/MPD/issues/377
Problem is the usage of the typedef `_IO_off64_t` in libroar's
`vio_stdio.h`:
int roar_vio_to_stdio_lseek (void *__cookie, _IO_off64_t *__pos, int __w);
This `_IO_off64_t` is an internal implementation detail of glibc and
was removed in version 2.28. Nobody must ever use it. Why the ****
did the RoarAudio developers use it? Not using internal typedefs
isn't exactly rocket science.
This annoys me enough to finally remove the plugin. Anyway, I've
never heard of anybody using RoarAudio, so my best guess is that
nobody will notice.
The compile-time calculation for `factor` overflows because `1<<31`
cannot be represented by `int`. By casting to `uintmax_t` first, we
can avoid this overflow.
Closes#380
Grouping in the "list" command was completely broken from the start,
unlike "count group". I have no idea what I have been thinking when I
wrote commit ae178c77bd, but it didn't
make any sense.
This commit is a rewrite of the feature.
For clients to be able to detect this feature, this commit also
increments the protocol version.
So long, autotools! This is my last MPD related project to migrate
away from it. It has its strengths, but also very obvious weaknesses
and weirdnesses. Today, many of its quirks are not needed anymore,
and are cumbersome and slow. Now welcome our new Meson overlords!
Previously, there was the setting `buffered_before_play` which
specified a percentage of the audio buffer, defaulting to `10%`. That
was working well enough for quite some time, until high-quality audio
formats became common.
At 44.1 kHz, 16 bit stereo, MPD collected 2.3 seconds worth of data in
the buffer before starting playback. With the same default settings
and 192 kHz, 24 bit stereo, that was only 0.27 seconds.
Making this depend on the byte size only leads to high latency at low
quality, and too little data at high quality. The natural choice
would be to use a duration instead of a byte size, which should give
the same good experience with all audio formats.
Since the `buffered_before_play` configuration setting was not
understood well by users and caused more harm than good, this commit
deprecates it. It has now no effect.
Simplify the formula, and I guess this makes the formula more
reliable. Imagine somebody configured `buffered_before_play` larger
than 25%; then the decoder would be woken up all the time. This
doesn't seem logical. On the other hand, it's easy to understand that
the decoder should be woken up below 75% buffer fill.
Apparently, Travis-CI will never upgrade its ancient Ubuntu Trusty,
so I have to get Boost from somewhere else.
Thanks to Martin Hierholzer for his PPA.
Since `this` was captured, it does not need to be specified, but GCC 6
can't do it. Since we want to support the standard compiler from
Debian Stretch (stable), we need to work around this problem:
src/neighbor/plugins/UdisksNeighborPlugin.cxx:239:12: error: cannot call member function 'void UdisksNeighborExplorer::Insert(UDisks2::Object&&)' without object
Insert(std::move(o));
~~~~~~^~~~~~~~~~~~~~
This fixes#300 which I previously thought was a different bug.
The API documentation says "move as much data as possible", and if
there is room at the head of the buffer, we should use that if the
room after the tail is not large enough.
- add Settings: Activity to start / stop MPD Service (Main).
- Main is a service that run in foreground with a notification. See
Service.startForeground documentation for more details.
- Main.Client is used to control the service: start or stop it and also receive
callbacks when service encounters an error, is killed, is started or is
stopped.
- Main.start to start the service without any fallback.
When using a database that was not created with a WebDAV music_directory
(i.e., if using a remote database, on which updates happen locally) and
using the Curl storage plugin, MPD would previously send GET requests that
had unescaped spaces in them. This change uses Curl's URL-encode API to
solve this.
Fixes problems with the Windows build because `-DCURL_STATICLIB` was
missing, causing error messages like:
"undefined reference to `__imp_curl_slist_free_all'"
With a "+" or "-" prefix, the "metadata_to_use" setting can manipulate
the existing default. This way, one can enable `TAG_COMMENT` without
having to list all the other tags.
the most notable bugs are
1. osx_output_set_device_format should use the target asbd rather than AudioFormat. This is because asbd's sample rate calculation reflects the real dop target rate of the DAC, white AudioFormat's sample rate is the original DSD format rate.
2. the original code value the highest rate that's the multiple of the target rate. This cause DOP always have the wrong rate chosen. This is also not necessary for PCM playback --- MPD's goal is bit perfect, and it's meaningless to raise to two or four times the PCM sample rate.
3. if sample_rate cannot be synchronized, the test for falling back to PCM is wrong. If the file format is in DSD format such fallback is necessary, whatever the params.dop setting is.
Deinitialize the logging library after the last exception handler,
because that one could still need it.
Use `AtScopeExit()` to ensure it's always called, even if an exception
was thrown.
the code here tried to guard DSD features behind ENABLE_DSD. However, the sample rate setting should be shared between two scenarios.
40a1ebee29 (diff-ce7ecec9ea9ca3df90d9c290cb3ef9d4R795)
The code runs fine if the dac supports the sample rate, as Mac OS will use the device rate if stream rate is 0.
However, when DAC is uncapable of processing the sample rate, a wrong rate (device rate) will be used for the stream rate.
This is kind of a revert of commit
b2e3c0757b, which is not any longer
necessary since commit 0dd4b52b63
removed the last call to `av_open_input_stream()`.
Instead of copying the offset from our `input`, copy the requested
offset to our `offset` attribute.
By the time Seek() finishes, our input's offset may have advanced
already, having read some more data, thus giving us a bogus offset.
This fixes spurious decoder failues (closes#320).
This fixes an old bug which caused the "unused" warnings to be
unreliable; only the first block in the list was marked as being
"used", no matter if it was really used, and the rest was never marked
as "used", suppressing all warnings for them.
Some Audio plugin (such as ALSA, and soon CoreAudio) already support microsecond level buffer time. However, current interval less than 1000 microseconds will cause a bug that the code treated as 0 ms.
some device seems to have issue with setting kAudioDevicePropertyVolumeScalar with kAudioObjectPropertyElementMaster. Use AudioToolbox 's kAudioHardwareServiceDeviceProperty_VirtualMasterVolume instead.
Ideally, we should get the steoro channels first, and set the kAudioDevicePropertyVolumeScalar for each channel, which is doable as presented in https://github.com/cmus/cmus/blob/master/op/coreaudio.c. I will do a follow up PR after refactor PR.
This PR will fix#271.
special thanks to @coroner21 who contributed a nice way to score hardware supported format in #292
Also, The DSD related code are all guarded with ENABLE_DSD flag.
- Update the mixer to set on device property instead of audio unit property. When user choose "hardware" as mixer type, they will be able to change the hardware device volume instead of the software (AudioUnit) volume.
- We don't use square root scale in volume calculation as previous code did. This will make the volume level in line with system volume meter --- That is, MPD will have the same percentage volume reading compared to System Setting (Either in "System Preference" or in "Audio Midi Setup" app)
After commit a72d1200fb, the Travis-CI
build fails, because we have been using GCC 5 there... so let's
switch to GCC 6 to test the oldest possible GCC version.
Since 7d353bbe2a, _GNU_SOURCE is always
defined, which implies __USE_MINGW_ANSI_STDIO and thus switches to
the mingw implementations of the printf() family. That's
standards-compliant, unlike Microsoft's CRT implementations.
This code was added in 21851c0673 but
looks completely broken:
- the status code is "206 OK" but "206" would be "Partial Content"
- the "Content-Length" header has a bogus value
- the "Content-RangeX" parameter has different bogus values (why
"Content-RangeX" anyway and not "Content-Range"?)
Apart from that, there are strange undocumented non-standard headers
which are probably there to work around bugs/expectations in one
broken proprietary client product. But these days, MPD doesn't bend
over to support broken clients. So let's kill this code.
Closes#304
For remote files (not streams), this downloads as quickly as possible
to a large buffer instead of throttling the stream during playback.
Throttling can make the server impatient and it may then disconnect.
This is what Qobuz and Tidal do, and this commit attempts to solve
this by not letting the Qobuz/Tidal server wait (closes#241).
This adds a bit of overhead, but also adds flexibility to the API,
because arbitrary triggers may be invoked from that virtual method
implementation, not just Cond::signal().
The motivation for this is to make the handlers more dynamic, for the
upcoming buffering class utilizing ProxyInputStream.
Those are loaded with the "curl" input plugin, and this one is
"expensive", because it needs to send a new HTTP request with Range
header for each seek.
To get udisks2 support started, this commit contains the configure.ac
option and a "neighbor" plugin which shows block devices. Later, this
will allow mounting removable media with a new storage plugin.
Error message sent to client was "basic_string::_M_construct null not
valid" due to passing nullptr to the std::string constructor.
Regression caused by commit 386688b87a
Don't reactivate the PCM device immediately after Cancel() is
finished; if Cancel() gets called this may mean that new data may take
a while to produce, or no data at all will be produced because the
current song is being stopped.
Once new data is available, Play() will automatically reactivate the
PCM.
This fixes underruns when switching songs manually (closes#264).
When switching to another song manually, the player checks if the
decoder is already decoding that song; if so, it will attempt to reuse
it by seeking it to the new position. That however fails if the
decoder is not seekable (e.g. a radio stream) which leaves the user
unable to switch to that song with the bogus error message "Not
seekable".
There was a discrepancy between what was written to the buffer and the
size returned by pcm_dsd_to_dop(): the "for" loop uses num_frames/2,
rounding down, while the return value is num_samples which is
num_frames*channels, without rounding. This could cause undefined
data at the end of the destination buffer if the source buffer size
was not aligned to multiples of 8 bytes (4 DSD bytes per channel).
The latter however can occur in the 0.21 branch after commit
a06bf388d9Closes#233
lockfree library used by ALSA output plugin is part of Boost from version 1.53,
so this can be theoretically the lowest required version, however
there are issues which are resolved from 1.54 onwards.
Instead of stopping playback (due to seek time overflow), reject the
seek command. Closes#240
Relative negative values (with "seekcur") are still allowed, and MPD
will fix the resulting position if it turns out to be negative. But
the "seek" and "seekid" commands use an unsigned time stamp which must
not be negative.
With Grand Central Dispatch used in Main.cxx, debug builds on macOS
crash as the IsInside() assertion gets triggered in the event loop. As
a simple fix, usage of GCD is removed. Plugging and unplugging
headphones or changes of the default output device was tested without
issues. Whatever the original commit tried to fix by GCD probably does
not need fixing anymore.
From: Christian Kröner <ckroener@gmx.net>
This just copies the necessary bits and pieces from the ALSA plugin and applies them to OSXOutput based on dop config setting. It only changes the OSXOutput plugin as needed for DoP (further changes to support additionally e.g. integer mode or setting the physical device mode require rather a complete rewrite of the output plugin).
Fortunately the Core Audio API is by default bit perfect and supports DoP with minimal changes (setting the sampling rate accordingly after ensuring that the physical mode supports at least 24 bits per channel seems to be enough). This was tested on an Amanero Combo384 device hooked up to a ES9018 DAC.
USAGE (try only on DACs that support DoP):
- Add dop "yes" option to mpdconf
- Be sure to set at least 24bits per channel before playing some DSD file (using Audio-MIDI-Setup)
- Based on the dop setting, MPD will change the sample rate as required and output DoP signal to the DAC
- Hog mode is recommended to ensure that no other program will try to mix some output with the DoP stream (resulting in bad noise)
- Alternatively set the default output device to another device (e.g. the built-in output) to avoid having other audio interfere with DSD playback
support for chaining ogg opus streams to enable changing stream' metadata on the fly.
currently support is opt-in (enabled by additional option) because lots of clients can't handle this properly yet.
configure.ac sets this, but this wasn't used for compiling third-party
libraries. This setting however is important for libnfs, which adds
fallback definitions for POLLIN and POLLOUT with bogus values.
libmad has been unmaintained for a long time, and it fails to build on
Windows. I could go and fix libmad's broken configure script, but I
prefer to just assign MP3 decoding to FFmpeg for now.
Closes#228
read_stream_art uses PRIu64 unconditionally with the Format
method of a Respone instance to output a size_t typed value.
If size_t is 32bit the output is garbeled. This patch uses
offset_type and PRIoffset to make sure the format string
and the type of the output value always match.
This addresses two problems:
1. the libFLAC write callback had to send an error status to its
caller when SubmitData() returned a command; this disrupted libFLAC
and the resulting command could not be used for anything;
2. the libFLAC function FLAC__stream_decoder_seek_absolute() also
calls the write callback, but its result cannot be used, because
seeking is still in progress, so we lose all data from one FLAC frame.
By moving the SubmitData() call until after CommandFinished(), we
avoid losing this data. This fixes another part of #113
Instead of passing whole chunks to the MusicPipe and checking the
end_time after each chunk, truncate the last chunk if it would exceed
the end_time. This requires keeping track of the absolute PCM frame
number.
This fixes a problem with gapless CUE song transitions: a small part
of the following song was always played twice.
Closes#113
The normal I/O event thread can have a large latency, e.g. when
libgnutls loads all TLS CA certificates for a https connect. This
makes it unreliable for the ALSA I/O notifications, and causes ring
buffer xruns. To avoid interfering with high latency events such as
CURL's, we move the ALSA I/O events to a separate I/O thread which
also obtains real-time scheduling (if possible).
Closes#221
Due to rounding errors, a slightly negative value can be passed to
set_normalized_volume(), which will make the log10() call fail.
Actually, volume 0 is already failing because log10(0) is illegal. So
let's fix this by implementing two corner cases: <=0 and >=100.
Closes#212
There is a POSIX definition for sched_setscheduler(), but Linux does
not implement that; instead of changing the process's scheduler, it
only affects one thread. This has caused some confusion among
application developers and C library developers.
While glibc implements Linux semantics, Musl has made their
sched_setscheduler() function an always-failing no-op, causing the
error message "sched_setscheduler failed: Function not implemented".
http://git.musl-libc.org/cgit/musl/commit/src/sched/sched_setscheduler.c?id=1e21e78bf7a5c24c217446d8760be7b7188711c2
Instead of relying on the C library which may be unreliable here, we
now roll our own system call wrapper.
Closes#218
Error message sent to client was "basic_string::_M_construct null not
valid" due to passing nullptr to the std::string constructor.
Regression caused by commit 386688b87a
Since 7d353bbe2a, _GNU_SOURCE is always
defined, which implies __USE_MINGW_ANSI_STDIO and thus switches to
the mingw implementations of the printf() family. That's
standards-compliant, unlike Microsoft's CRT implementations.
Android native code should be position-independent.
The NDK build scripts use "-fpic" instead of "-fPIC" for ARM, but that
doesn't work with FFmpeg's assembly code, because it requires
R_ARM_MOVW_ABS_NC which is unavailable with "-fpic".
The duration of a song can have fractions of seconds
(quote from http://www.upnp.org/schemas/av/didl-lite-v2.xsd):
The format of the duration string is:
H+:MM:SS[.F+], or H+:MM:SS[.F0/F1]
Where:
+H one or more digits to indicate elapsed hours,
MM exactly 2 digits to indicate minutes (00 to 59),
SS exactly 2 digits to indicate seconds (00 to 59),
F+ any number of digits (including no digits) to indicate fractions of seconds,
F0/F1 a fraction, with F0 and F1 at least one digit long,
and F0 < F1.
The string may be preceded by an optional + or - sign, and the
decimal point itself may be omitted if there are no fractional seconds digits.
Until now, a duration with fractions of seconds could not be parsed and
resulted in an unknown duration. Only durations in the format "H+:MM:SS"
were feasible. This commit enables to read durations in the first format,
i.e. "H+:MM:SS[.F+]"
Work around automake warning:
Makefile.am:310: warning: variable 'JAVA_SOURCES' is defined but no program or
Makefile.am:310: library has 'JAVA' as canonical name (possible typo)
Closes#195
Allows constructing the request first and set the URL later. This is
needed because curl_easy_escape() is needed to construct the URL,
which however needs the CURL "easy" handle created by the Request class.
The IcyMetaDataParser cannot be initialized already in OnHeaders(),
because it will be initialized late in that method; and there will not
be another OnHeaders() call, because streams with Icy metadata are not
seekable, thus there will not be another HTTP request.
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
Use the "==" operator instead of pthread_equal().
This allows us to eliminate two boolean flags which are there to avoid
race conditions, and made the thing so fragile that I got tons of
(correct) thread sanitizer warnings.
This fixes a build issue on Haiku as it does have sin_len.
Tested on Linux as well.
For some reason AC_CHECK_MEMBER doesn't generate the proper define
in config.h.in, so I used AC_CHECK_MEMBERS.
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.
.. and make all library symbols hidden by default.
Saves big amounts of .text section size with --gc-sections, because
only this allows discarding unused functions from those (static)
third-party libraries.
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)
The output plugin shall decide whether to insert silence or do nothing
at all. The ALSA output plugin has already implemented this.
Inserting silence is not necessary or helpful for some plugins, and
may even hurt them (e.g. "recorder").
Wohooooo, the method Filter::Reset() has been broken because no
implementation of it has ever been called for a loooong time.
And nobody ever noticed it. WTF.
Caused by commit 64d141f71e
This wasn't a serious memory leak, because after a mount failure, MPD
would abort anyway, which is subject to the next commit.
When the decoder is still starting up while we handle a SEEK, finish
the "player SEEK" immediately and re-enter the player loop, being able
to handle commands (and even cancel the pending seek).
This is the first part in a series of patches to solve the "blocking
input blocks decoder, blocks player, blocks the main thread" problem.
There are many other blocking code locations left, and the main thread
isn't non-blocking either because it waits for "seeking" to become
false.
The STOP, EXIT and CLOSE_AUDIO commands are not finished here; they
are propagated to PlayerControl::RunThread() where the
outputs.Cancel() call will be done again.
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.
Use the "==" operator instead of pthread_equal().
This allows us to eliminate two boolean flags which are there to avoid
race conditions, and made the thing so fragile that I got tons of
(correct) thread sanitizer warnings.
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.
After UnlockActivate() returns, we not only need to check for errors,
but also for more room in the ring buffer. If we don't check the ring
buffer, it may be drained already, and the cond.wait() call will never
finish.
Closes#151
Allows defining a list of supported audio formats, and allows
switching on and off DoP with certain formats.
This is a first rough draft. The setting syntax and its semantics may
still be redesigned.
There is no documentation on whether calling shout_metadata_add()
multiple times on one instance is allowed. To be sure, let's allocate
the object on demand each time in SendTag().
Passing it by value is actually smaller (32 bit) than the rvalue
reference (64 bit pointer), and it ensures that the object is consumed
after the call returns, no matter how the methods are implemented.
This loop was introduced in commit
24c1f46353, but -EPIPE is not a possible
error condition for snd_pcm_hw_params(). This code does not appear to
make sense. Problems with a wrong period_time should be caught before
that by snd_pcm_hw_params_set_period_time_near().
This commit removes the last "goto" in MPD! Yay!
Apparently, connecting a socket to a loopback address can block on
Windows, and a non-blocking socket will return WSAEINPROGRESS. This
broken PoorSocketPair() in commit 2119e4fd3e, which made the socket
non-blocking right from the start. This fix postpones the
ioctlsocket(FIONBIO) call until after the connect().
Closes#134
If you load an NSFE file (which has embedded track titles),
then attempt to load an M3U file, it causes GME to lose all
information found in the NSFE file. This adds a check that
the M3U file exists before attempting to load.
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.
Coverity discovered that the Pulse plugin could throw exceptions from
Pause(), but that method was marked "noexcept" because its caller was
not designed to catch exceptions. So instead of avoiding exceptions
(by catching and logging them in each and every implementation), let's
allow them, and do the catch/log game in the MPD core.
Fixes regression from commit 31bad5f7af:
if Pause() returns true, the output thread is running a busy loop,
causing 100% CPU usage, instead of just closing the output.
Closes#105
We can do CURL requests asynchronously, and we don't need a
synchronous WorkQueue thread for that.
This allows parallelizing lookups and allows immediate cancellation.
Will move attributes from struct AudioOutput that are specific to the
OutputThread. The new struct AudioOutputControl is a holder for the
AudioOutput pointer.
This prepares for making the output list more dynamic, to allow moving
outputs to between partitions.
Fixes false negatives:
http://foo/dav/example.ogg mismatches http://foo/dav/
.. because StringAfterPrefix() returns just "example.ogg", without
trailing slash (it existed, but was eaten already by the base
matcher).
With this commit, multi-player support becomes possible... it's just
not wired to the frontend yet.
This is based on massive amounts of refactoring work I did over the
past 9 years.
During UnlockActivate() while the mutex is unlocked, the IOThread can
set a new error condition, and will never again wake up the
OutputThread. This race condition can cause a deadlock in the
OutputThread.
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
The main EventLoop can block for a long time while a client's command
runs, and is therefore inappropriate for internal engine I/O. This
fixes a serious regression for at least the "httpd" output, which used
to be hard-coded for the IOThread, but now receives the main EventLoop
as an initialization parameter.
For the mixers, this doesn't make much of a difference. They are not
latency critical.
An explicit destructor prevents usage of implicit move operators, even
if it's empty. Therefore, declaring a defaulted destructor with GCC
attribute "noinline" does what we want without preventing those
implicit operators.
This reverts commit 67b7d46432.
Turns out I was wrong, and mentioning these does make a difference:
the implicit move constructor is not defined in the presence of a
user-declared destructor.
This is a guide for those who wish to hack on the MPD source code. MPD is an open project, and we are always happy about contributions. So far, more than 150 people have contributed patches. This document is work in progress. Most of it may be incomplete yet. Please help!
Code Style
==========
* indent with tabs (width 8)
* don't write CPP when you can write C++: use inline functions and constexpr instead of macros
* comment your code, document your APIs
* the code should be C++14 compliant, and must compile with :program:`GCC` 6.0 and :program:`clang` 3.4
* report error conditions with C++ exceptions, preferable derived from :envvar:`std::runtime_error`
* all code must be exception-safe
* classes and functions names use CamelCase; variables are lower-case with words separated by underscore
You can do without :code:`--rebase`, but we recommend that you rebase
your repository on the "master" repository all the time.
Configure with the option :code:`--werror`. Enable as many plugins as
possible, to be sure that you don't break any disabled code.
Don't mix several changes in one single patch. Create a separate patch for every change. Tools like :program:`stgit` help you with that. This way, we can review your patches more easily, and we can pick the patches we like most first.
Basic stgit usage
-----------------
stgit allows you to create a set of patches and refine all of them: you can go back to any patch at any time, and re-edit it (both the code and the commit message). You can reorder patches and insert new patches at any position. It encourages creating separate patches for tiny changes.
stgit needs to be initialized on a git repository:
..code-block::sh
stg init
Before you edit the code, create a patch:
..code-block::sh
stg new my-patch-name
stgit now asks you for the commit message.
Now edit the code. Once you're finished, you have to "refresh" the patch, i.e. your edits are incorporated into the patch you have created:
..code-block::sh
stg refresh
You may now continue editing the same patch, and refresh it as often as you like. Create more patches, edit and refresh them.
To view the list of patches, type stg series. To go back to a specific patch, type stg goto my-patch-name; now you can re-edit it (don't forget stg refresh when you're finished with that patch).
When the whole patch series is finished, convert stgit patches to git commits:
..code-block::sh
stg commit
Submitting Patches
==================
Send your patches to the mailing list:
Email: `mpd-devel <mpd-devel@musicpd.org>`_
:program:`git pull` requests are preferred.
Development Tools
=================
Clang Static Analyzer
---------------------
The `static analyzer <http://clang-analyzer.llvm.org/>`_ is a tool that helps find bugs. To run it on the MPD code base, install LLVM and clang. configure MPD to use clang:
Music Player Daemon (:program:`MPD`) is a flexible, powerful, server-side application for playing music. Through plugins and libraries it can play a variety of sound files while being controlled by its network protocol.
This document is work in progress. Most of it may be incomplete yet. Please help!
Installation
************
Installing on Debian/Ubuntu
---------------------------
Install the package :file:`mpd` via :program:`apt`:
..code-block::none
apt install mpd
When installed this way, :program:`MPD` by default looks for music in :file:`/var/lib/mpd/music/`; this may not be correct. Look at your :file:`/etc/mpd.conf` file...
..note::
Debian and Ubuntu are infamous for shipping heavily outdated
software. The :program:`MPD` version in their respective stable
releases are usually too old to be supported by this project.
Ironically, the :program:`MPD` version in Debian "*unstable*" is
more stable than the version in Debian "*stable*".
Installing on Android
---------------------
An experimental Android build is available on Google Play. After installing and launching it, :program:`MPD` will scan the music in your Music directory and you can control it as usual with a :program:`MPD` client.
If you need to tweak the configuration, you can create a file called :file:`mpd.conf` on the data partition (the directory which is returned by Android's :dfn:`getExternalStorageDirectory()` API function).
ALSA is not available on Android; only the :ref:`OpenSL ES
<sles_output>` output plugin can be used for local playback.
Compiling from source
---------------------
Download the source tarball from the `MPD home page <https://musicpd.org>`_ and unpack it:
..code-block::none
tar xf mpd-version.tar.xz
cd mpd-version
In any case, you need:
* a C++14 compiler (e.g. gcc 6.0 or clang 3.9)
*`Meson 0.47.2 <http://mesonbuild.com/>`__ and `Ninja
<https://ninja-build.org/>`__
* Boost 1.58
* pkg-config
Each plugin usually needs a codec library, which you also need to
install. Check the :doc:`plugins` for details about required libraries
For example, the following installs a fairly complete list of build dependencies on Debian Jessie:
The following command shows a list of compile-time options:
..code-block::none
meson configure output/release
When everything is ready and configured, compile:
..code-block::none
ninja -C output/release
And install:
..code-block::none
ninja -C output/release install
Compiling for Windows
---------------------
Even though it does not "feel" like a Windows application, :program:`MPD` works well under Windows. Its build process follows the "Linux style" and may seem awkward for Windows people (who are not used to compiling their software, anyway).
Basically, there are two ways to compile :program:`MPD` for Windows:
* Build as described above: with :program:`meson` and
:program:`ninja`. To cross-compile from Linux, you need `a Meson
The remaining difficulty is installing all the external libraries.
And :program:`MPD` usually needs many, making this method cumbersome
for the casual user.
* Build on Linux for Windows using :program:`MPD`'s library build script.
This section is about the latter.
Just like with the native build, unpack the :program:`MPD` source
tarball and change into the directory. Then, instead of
:program:`meson`, type:
..code-block::none
mkdir -p output/win64
cd output/win64
../../win32/build.py --64
This downloads various library sources, and then configures and builds
:program:`MPD` (for x64; to build a 32 bit binary, pass
:code:`--32`). The resulting EXE files is linked statically, i.e. it
contains all the libraries already and you do not need carry DLLs
around. It is large, but easy to use. If you wish to have a small
mpd.exe with DLLs, you need to compile manually, without the
:file:`build.py` script.
Compiling for Android
---------------------
:program:`MPD` can be compiled as an Android app. It can be installed easily with Google Play, but if you want to build it from source, follow this section.
You need:
* Android SDK
* Android NDK
Just like with the native build, unpack the :program:`MPD` source
tarball and change into the directory. Then, instead of
:envvar:`SDK_PATH` is the absolute path where you installed the
Android SDK; :envvar:`NDK_PATH` is the Android NDK installation path;
ABI is the Android ABI to be built, e.g. ":code:`arm64-v8a`".
This downloads various library sources, and then configures and builds :program:`MPD`.
systemd socket activation
-------------------------
Using systemd, you can launch :program:`MPD` on demand when the first client attempts to connect.
:program:`MPD` comes with two systemd unit files:a "service" unit and
a "socket" unit. These will be installed to the directory specified
with :code:`-Dsystemd_system_unit_dir=...`,
e.g. :file:`/lib/systemd/system`.
To enable socket activation, type:
..code-block::none
systemctl enable mpd.socket
systemctl start mpd.socket
In this configuration, :program:`MPD` will ignore the :ref:`listener
settings <listeners>` (``bind_to_address`` and ``port``).
systemd user unit
-----------------
You can launch :program:`MPD` as a systemd user unit. These will be
installed to the directory specified with
:code:`-Dsystemd_user_unit_dir=...`,
e.g. :file:`/usr/lib/systemd/user` or
:file:`$HOME/.local/share/systemd/user`.
Once the user unit is installed, you can start and stop :program:`MPD` like any other service:
..code-block::none
systemctl --user start mpd
To auto-start :program:`MPD` upon login, type:
..code-block::none
systemctl --user enable mpd
Configuration
*************
The Configuration File
----------------------
:program:`MPD` reads its configuration from a text file. Usually, that is :file:`/etc/mpd.conf`, unless a different path is specified on the command line. If you run :program:`MPD` as a user daemon (and not as a system daemon), the configuration is read from :file:`$XDG_CONFIG_HOME/mpd/mpd.conf` (usually :file:`~/.config/mpd/mpd.conf`). On Android, :file:`mpd.conf` will be loaded from the top-level directory of the data partition.
Each line in the configuration file contains a setting name and its value, e.g.:
:code:`connection_timeout "5"`
For settings which specify a filesystem path, the tilde is expanded:
:code:`music_directory "~/Music"`
Some of the settings are grouped in blocks with curly braces, e.g. per-plugin settings:
..code-block::none
audio_output {
type "alsa"
name "My ALSA output"
device "iec958:CARD=Intel,DEV=0"
mixer_control "PCM"
}
The :code:`include` directive can be used to include settings from
another file; the given file name is relative to the current file:
..code-block::none
include "other.conf"
Configuring the music directory
-------------------------------
When you play local files, you should organize them within a directory called the "music directory". This is configured in :program:`MPD` with the music_directory setting.
By default, :program:`MPD` follows symbolic links in the music directory. This behavior can be switched off: :code:`follow_outside_symlinks` controls whether :program:`MPD` follows links pointing to files outside of the music directory, and :code:`follow_inside_symlinks` lets you disable symlinks to files inside the music directory.
Instead of using local files, you can use storage plugins to access
files on a remote file server. For example, to use music from the
SMB/CIFS server ":file:`myfileserver`" on the share called "Music",
configure the music directory ":file:`smb://myfileserver/Music`". For
a recipe, read the Satellite :program:`MPD` section :ref:`satellite`.
You can also use multiple storage plugins to assemble a virtual music directory consisting of multiple storages.
Configuring database plugins
----------------------------
If a music directory is configured, one database plugin is used. To configure this plugin, add a database block to :file:`mpd.conf`:
..code-block::none
database {
plugin "simple"
path "/var/lib/mpd/db"
}
More information can be found in the :ref:`database_plugins`
reference.
Configuring neighbor plugins
----------------------------
All neighbor plugins are disabled by default to avoid unwanted overhead. To enable (and configure) a plugin, add a neighbor block to :file:`mpd.conf`:
..code-block::none
neighbors {
plugin "smbclient"
}
More information can be found in the :ref:`neighbor_plugin` reference.
Configuring input plugins
-------------------------
To configure an input plugin, add a input block to :file:`mpd.conf`:
..code-block::none
input {
plugin "curl"
proxy "proxy.local"
}
The following table lists the input options valid for all plugins:
..list-table::
:widths:20 80
:header-rows:1
* - Name
- Description
* - **plugin**
- The name of the plugin
* - **enabled yes|no**
- Allows you to disable a input plugin without recompiling. By default, all plugins are enabled.
More information can be found in the :ref:`input_plugins` reference.
Configuring decoder plugins
---------------------------
Most decoder plugins do not need any special configuration. To configure a decoder, add a decoder block to :file:`mpd.conf`:
..code-block::none
decoder {
plugin "wildmidi"
config_file "/etc/timidity/timidity.cfg"
}
The following table lists the decoder options valid for all plugins:
..list-table::
:widths:20 80
:header-rows:1
* - Name
- Description
* - **plugin**
- The name of the plugin
* - **enabled yes|no**
- Allows you to disable a decoder plugin without recompiling. By default, all plugins are enabled.
More information can be found in the :ref:`decoder_plugins` reference.
Configuring encoder plugins
---------------------------
Encoders are used by some of the output plugins (such as shout). The encoder settings are included in the audio_output section.
More information can be found in the :ref:`encoder_plugins` reference.
Configuring audio outputs
-------------------------
Audio outputs are devices which actually play the audio chunks produced by :program:`MPD`. You can configure any number of audio output devices, but there must be at least one. If none is configured, :program:`MPD` attempts to auto-detect. Usually, this works quite well with ALSA, OSS and on Mac OS X.
To configure an audio output manually, add one or more audio_output blocks to :file:`mpd.conf`:
..code-block::none
audio_output {
type "alsa"
name "my ALSA device"
device "hw:0"
}
The following table lists the audio_output options valid for all plugins:
..list-table::
:widths:20 80
:header-rows:1
* - Name
- Description
* - **type**
- The name of the plugin
* - **name**
- The name of the audio output. It is visible to the client. Some plugins also use it internally, e.g. as a name registered in the PULSE server.
* - **format**
- Always open the audio output with the specified audio format samplerate:bits:channels), regardless of the format of the input file. This is optional for most plugins.
Any of the three attributes may be an asterisk to specify that this attribute should not be enforced, example: 48000:16:*. *:*:* is equal to not having a format specification.
The following values are valid for bits: 8 (signed 8 bit integer samples), 16, 24 (signed 24 bit integer samples padded to 32 bit), 32 (signed 32 bit integer samples), f (32 bit floating point, -1.0 to 1.0), "dsd" means DSD (Direct Stream Digital). For DSD, there are special cases such as "dsd64", which allows you to omit the sample rate (e.g. dsd512:2 for stereo DSD512, i.e. 22.5792 MHz).
The sample rate is special for DSD: :program:`MPD` counts the number of bytes, not bits. Thus, a DSD "bit" rate of 22.5792 MHz (DSD512) is 2822400 from :program:`MPD`'s point of view (44100*512/8).
* - **enabed yes|no**
- Specifies whether this audio output is enabled when :program:`MPD` is started. By default, all audio outputs are enabled. This is just the default setting when there is no state file; with a state file, the previous state is restored.
* - **tags yes|no**
- If set to no, then :program:`MPD` will not send tags to this output. This is only useful for output plugins that can receive tags, for example the httpd output plugin.
* - **always_on yes|no**
- If set to yes, then :program:`MPD` attempts to keep this audio output always open. This may be useful for streaming servers, when you don't want to disconnect all listeners even when playback is accidentally stopped.
* - **mixer_type hardware|software|null|none**
- Specifies which mixer should be used for this audio output: the hardware mixer (available for ALSA :ref:`alsa_plugin`, OSS :ref:`oss_plugin` and PulseAudio :ref:`pulse_plugin`), the software mixer, the "null" mixer (null; allows setting the volume, but with no effect; this can be used as a trick to implement an external mixer :ref:`external_mixer`) or no mixer (none). By default, the hardware mixer is used for devices which support it, and none for the others.
Configuring filters
-------------------
Filters are plugins which modify an audio stream.
To configure a filter, add a filter block to :file:`mpd.conf`:
..code-block::none
filter {
plugin "volume"
name "software volume"
}
The following table lists the filter options valid for all plugins:
..list-table::
:widths:20 80
:header-rows:1
* - Name
- Description
* - **plugin**
- The name of the plugin
* - **name**
- The name of the filter
Configuring playlist plugins
----------------------------
Playlist plugins are used to load remote playlists (protocol commands load, listplaylist and listplaylistinfo). This is not related to :program:`MPD`'s playlist directory.
To configure a playlist plugin, add a playlist_plugin block to :file:`mpd.conf`:
..code-block::none
playlist_plugin {
name "m3u"
enabled "true"
}
The following table lists the playlist_plugin options valid for all plugins:
..list-table::
:widths:20 80
:header-rows:1
* - Name
- Description
* - **plugin**
- The name of the plugin
* - **enabled yes|no**
- Allows you to disable a playlist plugin without recompiling. By default, all plugins are enabled.
More information can be found in the :ref:`playlist_plugins`
reference.
Audio Format Settings
---------------------
Global Audio Format
~~~~~~~~~~~~~~~~~~~
The setting audio_output_format forces :program:`MPD` to use one audio format for all outputs. Doing that is usually not a good idea. The values are the same as in format in the audio_output section.
Resampler
~~~~~~~~~
Sometimes, music needs to be resampled before it can be played; for example, CDs use a sample rate of 44,100 Hz while many cheap audio chips can only handle 48,000 Hz. Resampling reduces the quality and consumes a lot of CPU. There are different options, some of them optimized for high quality and others for low CPU usage, but you can't have both at the same time. Often, the resampler is the component that is responsible for most of :program:`MPD`'s CPU usage. Since :program:`MPD` comes with high quality defaults, it may appear that :program:`MPD` consumes more CPU than other software.
Check the :ref:`resampler_plugins` reference for a list of resamplers
and how to configure them.
Client Connections
------------------
.._listeners:
Listeners
~~~~~~~~~
The setting :code:`bind_to_address` specifies which addresses
:program:`MPD` listens on for connections from clients. It can be
used multiple times to bind to more than one address. Example::
bind_to_address "192.168.1.42"
bind_to_address "127.0.0.1"
The default is "any", which binds to all available addresses.
Additionally, MPD binds to :code:`$XDG_RUNTIME_DIR/mpd/socket` (if it
was launched as a per-user daemon and no :code:`bind_to_address`
setting exists).
You can set a port that is different from the global port setting,
e.g. "localhost:6602". IPv6 addresses must be enclosed in square
brackets if you want to configure a port::
bind_to_address "[::1]:6602"
To bind to a local socket (UNIX domain socket), specify an absolute
path or a path starting with a tilde (~). Some clients default to
connecting to :file:`/var/run/mpd/socket` so this may be a good
choice::
bind_to_address "/var/run/mpd/socket"
If no port is specified, the default port is 6600. This default can
be changed with the port setting::
port "6601"
These settings will be ignored if `systemd socket activation`_ is
used.
Permissions and Passwords
~~~~~~~~~~~~~~~~~~~~~~~~~
By default, all clients are unauthenticated and have a full set of permissions. This can be restricted with the settings :code:`default_permissions` and :code:`password`.
:code:`default_permissions` controls the permissions of a new client. Its value is a comma-separated list of permissions:
..list-table::
:widths:20 80
:header-rows:1
* - Name
- Description
* - **read**
- Allows reading of the database, displaying the current playlist, and current status of :program:`MPD`.
* - **add**
- Allows adding songs and loading playlists.
* - **control**
- Allows all other player and playlist manipulations.
* - **admin**
- Allows database updates and allows shutting down :program:`MPD`.
:code:`local_permissions` may be used to assign other permissions to clients connecting on a local socket.
:code:`password` allows the client to send a password to gain other permissions. This option may be specified multiple times with different passwords.
Note that the :code:`password` option is not secure: passwords are sent in clear-text over the connection, and the client cannot verify the server's identity.
- Use only the specified tags, and ignore the others. This
setting can reduce the database size and :program:`MPD`'s
memory usage by omitting unused tags. By default, all tags but
comment are enabled. The special value "none" disables all
tags.
If the setting starts with ``+`` or ``-``, then the following
tags will be added or remoted to/from the current set of tags.
This example just enables the "comment" tag without disabling all
the other supported tags
metadata_to_use "+comment"
Section :ref:`tags` contains a list of supported tags.
The State File
~~~~~~~~~~~~~~
The state file is a file where :program:`MPD` saves and restores its state (play queue, playback position etc.) to keep it persistent across restarts and reboots. It is an optional setting.
:program:`MPD` will attempt to load the state file during startup, and will save it when shutting down the daemon. Additionally, the state file is refreshed every two minutes (after each state change).
..list-table::
:widths:20 80
:header-rows:1
* - Setting
- Description
* - **state_file PATH**
- Specify the state file location. The parent directory must be writable by the :program:`MPD` user (+wx).
* - **state_file_interval SECONDS**
- Auto-save the state file this number of seconds after each state change. Defaults to 120 (2 minutes).
The Sticker Database
~~~~~~~~~~~~~~~~~~~~
"Stickers" are pieces of information attached to songs. Some clients
use them to store ratings and other volatile data. This feature
These settings are various limitations to prevent :program:`MPD` from using too many resources (denial of service).
..list-table::
:widths:20 80
:header-rows:1
* - Setting
- Description
* - **connection_timeout SECONDS**
- If a client does not send any new data in this time period, the connection is closed. Clients waiting in "idle" mode are excluded from this. Default is 60.
* - **max_connections NUMBER**
- This specifies the maximum number of clients that can be connected to :program:`MPD` at the same time. Default is 5.
* - **max_playlist_length NUMBER**
- The maximum number of songs that can be in the playlist. Default is 16384.
* - **max_command_list_size KBYTES**
- The maximum size a command list. Default is 2048 (2 MiB).
* - **max_output_buffer_size KBYTES**
- The maximum size of the output buffer to a client (maximum response size). Default is 8192 (8 MiB).
Buffer Settings
~~~~~~~~~~~~~~~
Do not change these unless you know what you are doing.
..list-table::
:widths:20 80
:header-rows:1
* - Setting
- Description
* - **audio_buffer_size KBYTES**
- Adjust the size of the internal audio buffer. Default is 4096 (4 MiB).
Zeroconf
~~~~~~~~
If Zeroconf support (`Avahi <http://avahi.org/>`_ or Apple's Bonjour)
was enabled at compile time with :code:`-Dzeroconf=...`,
:program:`MPD` can announce its presence on the network. The following
settings control this feature:
..list-table::
:widths:20 80
:header-rows:1
* - Setting
- Description
* - **zeroconf_enabled yes|no**
- Enables or disables this feature. Default is yes.
* - **zeroconf_name NAME**
- The service name to publish via Zeroconf. The default is "Music Player @ %h".
%h will be replaced with the hostname of the machine running :program:`MPD`.
Advanced configuration
**********************
.._satellite:
Satellite setup
---------------
:program:`MPD` runs well on weak machines such as the Raspberry Pi. However, such hardware tends to not have storage big enough to hold a music collection. Mounting music from a file server can be very slow, especially when updating the database.
One approach for optimization is running :program:`MPD` on the file server, which not only exports raw files, but also provides access to a readily scanned database. Example configuration:
..code-block::none
music_directory "nfs://fileserver.local/srv/mp3"
#music_directory "smb://fileserver.local/mp3"
database {
plugin "proxy"
host "fileserver.local"
}
The :code:`music_directory` setting tells :program:`MPD` to read files from the given NFS server. It does this by connecting to the server from userspace. This does not actually mount the file server into the kernel's virtual file system, and thus requires no kernel cooperation and no special privileges. It does not even require a kernel with NFS support, only the nfs storage plugin (using the libnfs userspace library). The same can be done with SMB/CIFS using the smbclient storage plugin (using libsmbclient).
The database setting tells :program:`MPD` to pass all database queries on to the :program:`MPD` instance running on the file server (using the proxy plugin).
Real-Time Scheduling
--------------------
On Linux, :program:`MPD` attempts to configure real-time scheduling for some threads that benefit from it.
This is only possible you allow :program:`MPD` to do it. This privilege is controlled by :envvar:`RLIMIT_RTPRIO`:envvar:`RLIMIT_RTTIME`. You can configure this privilege with :command:`ulimit` before launching :program:`MPD`:
..code-block::none
ulimit -HS -r 50; mpd
Or you can use the :command:`prlimit` program from the util-linux package:
..code-block::none
prlimit --rtprio=50 --rttime=unlimited mpd
The systemd service file shipped with :program:`MPD` comes with this setting.
This works only if the Linux kernel was compiled with :makevar:`CONFIG_RT_GROUP_SCHED` disabled. Use the following command to check this option for your current kernel:
..code-block::none
zgrep ^CONFIG_RT_GROUP_SCHED /proc/config.gz
You can verify whether the real-time scheduler is active with the ps command:
..code-block::none
# ps H -q `pidof -s mpd` -o 'pid,tid,cls,rtprio,comm'
PID TID CLS RTPRIO COMMAND
16257 16257 TS - mpd
16257 16258 TS - io
16257 16259 FF 50 rtio
16257 16260 TS - player
16257 16261 TS - decoder
16257 16262 FF 50 output:ALSA
16257 16263 IDL 0 update
The CLS column shows the CPU scheduler; TS is the normal scheduler; FF and RR are real-time schedulers. In this example, two threads use the real-time scheduler: the output thread and the rtio (real-time I/O) thread; these two are the important ones. The database update thread uses the idle scheduler ("IDL in ps), which only gets CPU when no other process needs it.
Note
~~~~
There is a rumor that real-time scheduling improves audio quality. That is not true. All it does is reduce the probability of skipping (audio buffer xruns) when the computer is under heavy load.
Using MPD
*********
The client
----------
After you have installed, configured and started :program:`MPD`, you choose a client to control the playback.
The most basic client is :program:`mpc`, which provides a command line interface. It is useful in shell scripts. Many people bind specific :program:`mpc` commands to hotkeys.
The `MPD Wiki <http://www.musicpd.org/clients/>`_ contains an extensive list of clients to choose from.
The music directory and the database
------------------------------------
The "music directory" is where you store your music files. :program:`MPD` stores all relevant meta information about all songs in its "database". Whenever you add, modify or remove songs in the music directory, you have to update the database, for example with mpc:
..code-block::none
mpc update
Depending on the size of your music collection and the speed of the storage, this can take a while.
To exclude a file from the update, create a file called :file:`.mpdignore` in its parent directory. Each line of that file may contain a list of shell wildcards. Matching files in the current directory and all subdirectories are excluded.
Mounting other storages into the music directory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:program:`MPD` has various storage plugins of which multiple instances can be "mounted" into the music directory. This way, you can use local music, file servers and USB sticks at the same time. Example:
..code-block::none
mpc mount foo nfs://192.168.1.4/export/mp3
mpc mount usbstick udisks://by-uuid-2F2B-D136
mpc unmount usbstick
:program:`MPD`'s neighbor plugins can be helpful with finding mountable storages:
..code-block::none
mpc listneighbors
Mounting is only possible with the simple database plugin and a :code:`cache_directory`, e.g.:
..code-block::none
database {
plugin "simple"
path "~/.mpd/db"
cache_directory "~/.mpd/cache"
}
This requires migrating from the old :code:`db_file` setting to a database section. The cache directory must exist, and :program:`MPD` will put one file per mount there, which will be reused when the same storage is used again later.
Metadata
--------
When scanning or playing a song, :program:`MPD` parses its metadata.
See :ref:`tags` for a list of supported tags.
The :ref:`metadata_to_use <metadata_to_use>` setting can be used to
enable or disable certain tags.
The queue
---------
The queue (sometimes called "current playlist") is a list of songs to be played by :program:`MPD`. To play a song, add it to the queue and start playback. Most clients offer an interface to edit the queue.
Stored Playlists
----------------
Stored playlists are some kind of secondary playlists which can be created, saved, edited and deleted by the client. They are addressed by their names. Its contents can be loaded into the queue, to be played back. The playlist_directory setting specifies where those playlists are stored.
Advanced usage
**************
Bit-perfect playback
--------------------
"Bit-perfect playback" is a phrase used by audiophiles to describe a setup that plays back digital music as-is, without applying any modifications such as resampling, format conversion or software volume. Naturally, this implies a lossless codec.
By default, :program:`MPD` attempts to do bit-perfect playback, unless you tell it not to. Precondition is a sound chip that supports the audio format of your music files. If the audio format is not supported, :program:`MPD` attempts to fall back to the nearest supported audio format, trying to lose as little quality as possible.
To verify if :program:`MPD` converts the audio format, enable verbose logging, and watch for these lines:
..code-block::none
decoder: audio_format=44100:24:2, seekable=true
output: opened plugin=alsa name="An ALSA output"audio_format=44100:16:2
output: converting from 44100:24:2
This example shows that a 24 bit file is being played, but the sound chip cannot play 24 bit. It falls back to 16 bit, discarding 8 bit.
However, this does not yet prove bit-perfect playback; ALSA may be fooling :program:`MPD` that the audio format is supported. To verify the format really being sent to the physical sound chip, try:
..code-block::none
cat /proc/asound/card*/pcm*p/sub*/hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 4096
buffer_size: 16384
Obey the "format" row, which indicates that the current playback format is 16 bit (signed 16 bit integer, little endian).
Check list for bit-perfect playback:
* Use the ALSA output plugin.
* Disable sound processing inside ALSA by configuring a "hardware" device (hw:0,0 or similar).
* Don't use software volume (setting mixer_type).
* Don't force :program:`MPD` to use a specific audio format (settings format, audio_output_format).
* Verify that you are really doing bit-perfect playback using :program:`MPD`'s verbose log and :file:`/proc/asound/card*/pcm*p/sub*/hw_params`. Some DACs can also indicate the audio format.
Direct Stream Digital (DSD)
---------------------------
DSD (`Direct Stream Digital <https://en.wikipedia.org/wiki/Direct_Stream_Digital>`_) is a digital format that stores audio as a sequence of single-bit values at a very high sampling rate.
:program:`MPD` understands the file formats dff and dsf. There are three ways to play back DSD:
* Native DSD playback. Requires ALSA 1.0.27.1 or later, a sound driver/chip that supports DSD and of course a DAC that supports DSD.
* DoP (DSD over PCM) playback. This wraps DSD inside fake 24 bit PCM according to the DoP standard. Requires a DAC that supports DSD. No support from ALSA and the sound chip required (except for bit-perfect 24 bit PCM support).
* Convert DSD to PCM on-the-fly.
Native DSD playback is used automatically if available. DoP is only used if enabled explicitly using the dop option, because there is no way for :program:`MPD` to find out whether the DAC supports it. DSD to PCM conversion is the fallback if DSD cannot be used directly.
Client Hacks
************
.._external_mixer:
External Mixer
--------------
The setting :code:`mixer_type "null"` asks MPD to pretend that there is a mixer, but not actually do something. This allows you to implement a :program:`MPD` client which listens for mixer events, queries the current (fake) volume, and uses it to program an external mixer. For example, your client can forward this setting to your amplifier.
Troubleshooting
***************
Where to start
--------------
Make sure you have the latest :program:`MPD` version (via :code:`mpd --version`, not mpc version). All the time, bugs are found and fixed, and your problem might be a bug that is fixed already. Do not ask for help unless you have the latest :program:`MPD` version. The most common excuse is when your distribution ships an old :program:`MPD` version - in that case, please ask your distribution for help, and not the :program:`MPD` project.
Check the log file. Configure :code:`log_level "verbose"` or pass :option:`--verbose` to mpd.
Sometimes, it is helpful to run :program:`MPD` in a terminal and follow what happens. This is how to do it:
..code-block::none
mpd --stdout --no-daemon --verbose
Support
-------
Getting Help
~~~~~~~~~~~~
The :program:`MPD` project runs a `forum <https://forum.musicpd.org/>`_ and an IRC channel (#mpd on Freenode) for requesting help. Visit the MPD help page for details on how to get help.
Common Problems
~~~~~~~~~~~~~~~
1. Database
^^^^^^^^^^^
Question: I can't see my music in the MPD database!
* Does the MPD user have read permission on all music files, and read+execute permission on all music directories (and all of their parent directories)?
* Did you update the database? (mpc update)
* Did you enable all relevant decoder plugins at compile time? :command:`mpd --version` will tell you.
Question: MPD doesn't read ID3 tags!
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
* You probably compiled :program:`MPD` without libid3tag. :command:`mpd --version` will tell you.
2. Playback
^^^^^^^^^^^
Question: I can't hear music on my client!
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
* That problem usually follows a misunderstanding of the nature of :program:`MPD`. :program:`MPD` is a remote-controlled music player, not a music distribution system. Usually, the speakers are connected to the box where :program:`MPD` runs, and the :program:`MPD` client only sends control commands, but the client does not actually play your music.
:program:`MPD` has output plugins which allow hearing music on a remote host (such as httpd), but that is not :program:`MPD`'s primary design goal.
Question: "Device or resource busy"
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
* This ALSA error means that another program uses your sound hardware exclusively. You can stop that program to allow :program:`MPD` to use it.
Sometimes, this other program is PulseAudio, which can multiplex sound from several applications, to allow them to share your sound chip. In this case, it might be a good idea for :program:`MPD` to use PulseAudio as well, instead of using ALSA directly.
Reporting Bugs
--------------
If you believe you found a bug in :program:`MPD`, report it on the `bug tracker <https://github.com/MusicPlayerDaemon/MPD/issues>`_.
Your bug report should contain:
* the output of :command:`mpd --version`
* your configuration file (:file:`mpd.conf`)
* relevant portions of the log file (:option:`--verbose`)
* be clear about what you expect MPD to do, and what is actually happening
MPD crashes
~~~~~~~~~~~
All :program:`MPD` crashes are bugs which must be fixed by a developer, and you should write a bug report. (Many crash bugs are caused by codec libraries used by :program:`MPD`, and then that library must be fixed; but in any case, the :program:`MPD``bug tracker <https://github.com/MusicPlayerDaemon/MPD/issues>`_ is a good place to report it first if you don't know.)
A crash bug report needs to contain a "backtrace".
First of all, your :program:`MPD` executable must not be "stripped"
(i.e. debug information deleted). The executables shipped with Linux
distributions are usually stripped, but some have so-called "debug"
packages (package :file:`mpd-dbgsym` or :file:`mpd-dbg` on Debian,
:file:`mpd-debug` on other distributions). Make sure this package is
installed.
If you built :program:`MPD` from sources, please recompile with Meson
option ":code:`--buildtype=debug -Db_ndebug=false`", because this will
add more helpful information to the backtrace.
You can extract the backtrace from a core dump, or by running :program:`MPD` in a debugger, e.g.:
..code-block::none
gdb --args mpd --stdout --no-daemon --verbose
run
As soon as you have reproduced the crash, type ":command:`bt`" on the
gdb command prompt. Copy the output to your bug report.
# Copyright (c) 2008 Thomas Porschberg <thomas@randspringer.de>
# Copyright (c) 2009 Peter Adolphs
#
# Copying and distribution of this file, with or without modification, are
# permitted in any medium without royalty provided the copyright notice
# and this notice are preserved. This file is offered as-is, without any
# warranty.
#serial 27
AC_DEFUN([AX_BOOST_BASE],
[
AC_ARG_WITH([boost],
[AS_HELP_STRING([--with-boost@<:@=ARG@:>@],
[use Boost library from a standard location (ARG=yes),
from the specified location (ARG=<path>),
or disable it (ARG=no)
@<:@ARG=yes@:>@ ])],
[
if test "$withval" = "no"; then
want_boost="no"
elif test "$withval" = "yes"; then
want_boost="yes"
ac_boost_path=""
else
want_boost="yes"
ac_boost_path="$withval"
fi
],
[want_boost="yes"])
AC_ARG_WITH([boost-libdir],
AS_HELP_STRING([--with-boost-libdir=LIB_DIR],
[Force given directory for boost libraries. Note that this will override library path detection, so use this parameter only if default library detection fails and you know exactly where your boost libraries are located.]),
if test "$V_CHECK" = "1" -a "$ac_boost_lib_path" = "" ; then
AC_MSG_NOTICE(We will use a staged boost library from $BOOST_ROOT)
BOOST_CPPFLAGS="-I$BOOST_ROOT"
BOOST_LDFLAGS="-L$BOOST_ROOT/stage/$libsubdir"
fi
fi
fi
fi
CPPFLAGS="$CPPFLAGS $BOOST_CPPFLAGS"
export CPPFLAGS
LDFLAGS="$LDFLAGS $BOOST_LDFLAGS"
export LDFLAGS
AC_LANG_PUSH(C++)
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
@%:@include <boost/version.hpp>
]], [[
#if BOOST_VERSION >= $WANT_BOOST_VERSION
// Everything is okay
#else
# error Boost version is too old
#endif
]])],[
AC_MSG_RESULT(yes)
succeeded=yes
found_system=yes
],[
])
AC_LANG_POP([C++])
fi
if test "$succeeded" != "yes" ; then
if test "$_version" = "0" ; then
AC_MSG_NOTICE([[We could not detect the boost libraries (version $boost_lib_version_req_shorten or higher). If you have a staged boost library (still not installed) please specify \$BOOST_ROOT in your environment and do not give a PATH to --with-boost option. If you are sure you have boost installed, then check your version number looking in <boost/version.hpp>. See http://randspringer.de/boost for more documentation.]])
else
AC_MSG_NOTICE([Your boost libraries seems to old (version $_version).])
fi
# execute ACTION-IF-NOT-FOUND (if present):
ifelse([$3], , :, [$3])
else
AC_SUBST(BOOST_CPPFLAGS)
AC_SUBST(BOOST_LDFLAGS)
AC_DEFINE(HAVE_BOOST,,[define if the Boost library is available])
* Copyright 2003-2017 The Music Player Daemon Project
* Copyright 2003-2018 The Music Player Daemon Project
* http://www.musicpd.org
*
* This program is free software; you can redistribute it and/or modify
@@ -24,15 +24,15 @@
#include"LogLevel.hxx"
void
SetLogThreshold(LogLevel_threshold);
SetLogThreshold(LogLevel_threshold)noexcept;
void
EnableLogTimestamp();
EnableLogTimestamp()noexcept;
void
LogInitSysLog();
LogInitSysLog()noexcept;
void
LogFinishSysLog();
LogFinishSysLog()noexcept;
#endif /* LOG_H */
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.