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

Yet another C-style vtable replaced with C++.

Hide struct FilteredAudioOutput from the plugins, preparing for hiding
MPD's core internals.

Prepare to add an abstract class AudioOutput, to be implemented by
plugins, to get rid of the C-style vtable.

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.

Eliminate dependency on io_thread_get().

Beware, this commit was not tested.  I don't have OS X, but I want to
prepare an API change.

Eliminate all those "goto"s and make the function exception-safe.

This further optimize the performance. 

This is now working properly with a conditional variable bug being fixed (8bbfb5cd).

do not hog system device.

which ensures mpd do bit perfect playback on OS X

Closes https://bugs.musicpd.org/view.php?id=4537 .

Removed the 'cancel' function because it violates 'single producer,
single consumer'.

In e068d62a I added code that zeros the remainder of the output buffer
if there are not enough input frames available. I have now learned
that we can signal to the caller of the render callback how much data
is in the output buffers. In practice, the input buffer is so large
that it does not matter so much how we handle input buffer underruns,
but I suppose that saying 'there is no data' is better than 'here is
some silence for you'.

The old struct config_param remains only for top-level string options.