Closed ChunMinChang closed 2 months ago
According to BMO 1904734 comment #10, it seems kAudioUnitProperty_AudioChannelLayout setting should be applied if only FrontLeft
and FrontRight
are meaningful in the channel layout, e.g, [ .., Discrete, ...., FrontLeft, ..., FrontRight, ..., Silence, ...]
. We could probably add a device_layout
inspection in the if conditions for maybe_need_mixer
.
Currently, #233 partially addresses the issue. Other commits/patches are required to fix the problem.
When playing stereo, audio should come out of the stereo pair, is that not what you're expecting?
Testing with Blackhole16ch, having set Front Left to ch7 and Front Right to ch8 and playing stereo audio with test_tone I get the left channel playing through ch7 and the right through ch8 as expected. Mono got downmixed (half volume or so) to ch7 and ch8. With #233 I got Mono at full volume to ch3 instead (Center).
I guess this is the difference in mixer behavior when outputting 8ch (with a Center channel) vs 2ch (without Center).
Here is the brief of the offline discussion:
I am going to close this since #233 solves the channel count issue and leads to addressing the needs above.
This issue is mirrored from BMO 1904734, as detailed in comments #6 and #7.
On my Cubilux Surround Sound Card (CA7), the channel layout is set to
[BackLeft, BackRight, FrontCenter, LowFrequency, FrontLeft, FrontRight]
. However, audio only comes out of the first two channels when tested in Firefox and withtest_tone
. With a 2-channel input and a 6-channel output, a Mixer should be created to upmix the audio.I am not sure what
kAudioUnitProperty_AudioChannelLayout
setting is supposed to do, but it doesn't seem to change my Cubilux device setting. Instead, it setsmaybe_need_mixer
tofalse
, preventing the mixer from being created.Commenting out the
kAudioUnitProperty_AudioChannelLayout
setting doesn't solve the problem, as theoutput_dev_desc
'smChannelsPerFrame
still reports2
. This leads to creating a 2-channel output mixer, even though thedevice_layout
correctly reflects the channel layout.The channels of
output_dev_desc
are defined byoutput_hw_desc.mChannelsPerFrame
, which is expected to reflect the hardware information. However, it also reports2
in this case. Theoutput_hw_desc
is queried from thekAudioUnitProperty_StreamFormat property
. Changing the query scope fromkAudioUnitScope_Input
tokAudioUnitScope_Output
makesoutput_hw_desc
report the expectedmChannelsPerFrame
value of6
, resulting in anoutput_dev_desc
setting that allows the creation of a 6-channel output mixer.In summary, commenting out the
kAudioUnitProperty_AudioChannelLayout
setting and changing the query scope forkAudioUnitProperty_StreamFormat
fixes the issue. These changes were introduced in PR #220 and PR #222. However, there were no comments or explanations detailing the issues they were meant to address. Without this context, I am unsure if reverting these changes is the right approach or if it might lead to other regressions.@Pehrsons, @padenot, do you remember what those settings do? I'd like to leave some discussion here or on the bug for future reference. Feel free to comment with your thoughts about the right approach.