Use correct number of channels for the selected CoreAudio stream #422
Conversation
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.
|
I know very little about this API, but I wasn't sure if this is the correct approach versus modifying the |
|
@garyscavone I believe this is a pretty bad bug, which causes very bad audio distortion (and possibly crashes) when using certain interfaces on OSX. |
|
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. |
|
Many thanks! |
The
kAudioStreamPropertyPhysicalFormatquery 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.