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.
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.
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.
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
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.
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!
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.
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 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 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)
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
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).
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
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").
These attributes are printed in the "outputs" response, and the new
command "outputset" allows setting new values.
No attributes are currently implemented.
[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.
This fixes spurious replay gain logs when the player inserts silence
chunks, because those silence chunks had no replay gain attached,
resetting the ReplayGainFilter state, flipping it forth and back.
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
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
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!
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
