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. 

https://github.com/MusicPlayerDaemon/MPD/commit/40a1ebee295c569521ea17ffdedc641d1aedd9cb#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 method was added in Boost 1.58.

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.

1 sec for pause is too long. we wait for the same amount of time as when ring buffer is not available for writing.

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 21851c06 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

See code comment.  Closes #260

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

Use the "active" flag in PrepareSockets() instead of LockHasError().

Prepare to make the "active" attribute thread-safe.

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 PulseOutput needs to be "enabled" before WaitConnection() may be
called.

Closes #207