search

thestk / rtaudio

A set of C++ classes that provide a common API for realtime audio input/output across Linux (native ALSA, JACK, PulseAudio and OSS), Macintosh OS X (CoreAudio and JACK), and Windows (DirectSound, ASIO, and WASAPI) operating systems.
Other
1.49k stars 317 forks source link

Use correct number of channels for the selected CoreAudio stream #422

Closed mikedickey closed 6 months ago

mikedickey commented 6 months ago

The kAudioStreamPropertyPhysicalFormat query returns the number of channels for the device's first audio stream. If any single, subsequent stream is selected to fulfill the user request, it may use a different number of channels. This mismatch can cause a lot of problems.

mikedickey commented 6 months ago

I know very little about this API, but I wasn't sure if this is the correct approach versus modifying the AudioObjectGetPropertyData commands so that the stream id is passed into them? Perhaps that is what the inQualifierData fields are for?

mikedickey commented 6 months ago

@garyscavone I believe this is a pretty bad bug, which causes very bad audio distortion (and possibly crashes) when using certain interfaces on OSX.

garyscavone commented 6 months ago

The relevant code is quite old. I don't disagree that this may be a bug but I'm surprised it hasn't been flagged earlier. Part of the problem is that the whole multiple-stream per device scenario is quite confusing and almost impossible to test adequately. Just to confirm, you did experience poor audio and this proposed change fixed it? Do you know what audio device it happened with?

mikedickey commented 6 months ago

The relevant code is quite old. I don't disagree that this may be a bug but I'm surprised it hasn't been flagged earlier. Part of the problem is that the whole multiple-stream per device scenario is quite confusing and almost impossible to test adequately. Just to confirm, you did experience poor audio and this proposed change fixed it? Do you know what audio device it happened with?

@garyscavone Yes, specifically I encountered this when using an RME Babyface Pro FS device. It reports several streams, which total up to the 12 channels supported. If you use channels from the first stream (0-3) it works fine. If you try to use channels 4+ the callback is triggered with a different number of channels (2 versus 4 if I remember correctly), and this causes really bad audio garble.

This fix ensures that the number of channels expected by the callback is correct regardless of which stream is chosen, and the number of channels on it. After applying it all channels including 4-11 work great with the RME.

garyscavone commented 6 months ago

Many thanks!