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