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
[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.
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().
