`audiounit_get_{current,preferred}_channel_layout` behaves differently on recent MacBook Pro

[kinetiknz]

On a mid-2018 MacBook Pro (MacBookPro15,1 running 10.14) using the default speakers, test_get_current_channel_layout_output and test_get_preferred_channel_layout_output fail with:

thread 'backend::tests::api::test_get_current_channel_layout_output' panicked at 'assertion failed: `(left == right)`
  left: `[Silence, Silence]`,
 right: `[FrontLeft, FrontRight]`', src/backend/tests/api.rs:782:9

For whatever reason, the AudioChannelLayout queried via AudioUnitGetProperty(kAudioUnitProperty_AudioChannelLayout) appears to be valid/correctly initialized (52 bytes) but is mostly filled with zero values:

AudioChannelLayout.mChannelLayoutTag == kAudioChannelLayoutTag_UseChannelDescriptions (0),
AudioChannelLayout.mChannelBitmap == 0,
AudioChannelLayout.mNumberChannelDescriptions == 2,
{
  AudioChannelDescription.mChannelLabel == 0,
  AudioChannelDescription.mChannelFlags == 0,
  AudioChannelDescription.mCoordinates == [0.0, 0.0, 0.0],
},
{
  AudioChannelDescription.mChannelLabel == 0,
  AudioChannelDescription.mChannelFlags == 0,
  AudioChannelDescription.mCoordinates == [0.0, 0.0, 0.0],
}

...which results in audiounit_convert_channel_layout returning a Vec of [mixer::Channel::Silence, mixer::Channel::Silence], causing the tests expecting [mixer::Channel::FrontLeft, mixer::Channel::FrontRight] to fail.

It's not clear to me the correct way to handle this situation. Whether it's correct or not, I noticed that other code querying kAudioUnitProperty_AudioChannelLayout often treats AudioChannelLayout.mNumberChannelDescriptions <= 2 as special and forces mono/stereo examining the AudioChannelDescriptions only for the > 2 case.

FWIW, kAudioUnitProperty_SupportedChannelLayoutTags in the same context returns kAudioUnitErr_InvalidProperty.

Chun-Min mentioned that @padenot has seen the same issue on a 2019 MBP.

[padenot]

I do, but my macbook is also a 2018.

[ChunMinChang]

It's not clear to me the correct way to handle this situation. Whether it's correct or not, I noticed that other code querying kAudioUnitProperty_AudioChannelLayout often treats AudioChannelLayout.mNumberChannelDescriptions <= 2 as special and forces mono/stereo examining the AudioChannelDescriptions only for the > 2 case.

Actually, that's what we currently do. We force the 1-channel and 2-channel layout to be mono and stereo: https://github.com/ChunMinChang/cubeb-coreaudio-rs/blob/e8b8a052d8ce716c6a6f846d3a6fd4deea2d5ed8/src/backend/mixer.rs#L199-L206

I think we can simply remove the hardcode predefined values in the test.