Loopback testing of 2AMi2o2xxxxxx on macOS was failing the ramp test with large discontinuities.
Manual testing shows that macOS defaults to 44100 16-bit profile for this config.
Inspection of the USB frames reveals that that only the top 16 bits are being sent.
selecting a 24-bit profile on the host resolves the issue but the change is not persistent across multiple xruns,
it also doesn't allow testing of both 24-bit and 16-bit profiles
portaudio provides the stream format flags paMacCoreChangeDeviceParameters and paMacCoreFailIfConversionRequired which are set by xsig
kAudioDevicePropertyStreamFormat was deprecated in macOS 10.8
kAudioStreamPropertyPhysicalFormat is used by JUCE
kAudioUnitProperty_StreamFormat is used by portaudio
both are used by mpv
mpv hangs on playback when the stream format doesn't match the device format but seems unable to set the format, playback starts when the correct bit depth is selected in the Audio Midi Settings UI
macOS 10.15 introduced kAppleLosslessFormatFlag_24BitSourceData which is probably the current "proper" way to define the stream type
windows testing:
both the built in windows driver and the Thesycon driver default to 24-bits, if the bitdepth is manually set to 16-bit before test run then they both fail with similar results to the mac.
a fix would be required before testing at all supported bitdepths
current solution:
testing of the config at issue has been moved to the windows test machines where it defaults to the correct settings.
long term solutions:
update from portaudio may fix this in the future
we work on a fix for portaudio and submit a PR
move to a different cross-platform audio library (would require some to complete rewrite of xsig)
the rust crate cpal claims to support the desired functionality
Initial observation:
Loopback testing of 2AMi2o2xxxxxx on macOS was failing the ramp test with large discontinuities.
windows testing:
current solution:
long term solutions: