Channel layout detection for the destination output device

[pmlt]

Describe the feature The current WebAudio API allows us to know the maximum number of output channels for a destination via AudioDestinationNode.maxChannelCount. However, this information gives us no indication of the nature of each channel (is it LFE?) and their ordering. For example, a value of "6" might mean a standard 5.1 setup, or it might mean standard 6.0, or just 6 arbitrary outputs.

Most platforms usually expose an OS-level API to obtain this information. It should be passed down to users of AudioContext.

Is there a prototype? No prototyping is possible.

Describe the feature in more detail On Windows, the WAVEFORMATEXTENSIBLE structure can be obtained for any output device. This structure contains a bitfield of channel positions.

On Mac, the kAudioDevicePropertyPreferredChannelLayout property can be used to obtain the channel layout.

On the Web Audio side, the information could be translated as an additional channelLayout enum on AudioDestinationNode. This enum would contain all possible values of the supported layouts in the Web Audio spec (https://webaudio.github.io/web-audio-api/#ChannelLayouts). I would suggest also adding 7.1 to this list at least, but perhaps this belongs in a separate issue.

[padenot]

TPAC 2020:

• This exposes more info about a user configuration, and is more about the device itself than about something AudioContext related, it might make sense to do this on device info, that would handle the user consent bits, etc.
• Audio output is always SMPTE order on the Web Audio API, and the remapped by the implementation to match the channel layout that the user has (this is very cheap operation, shuffling pointers around once per system level audio callback)
• The fact that it only goes up to 5.1 is an historical artifact, this can be fixed
• The Web Audio API and implementations don't do anything with the audio that is sent to the OS except reordering

[padenot]

AudioWG virtual F2F:

• Adding 7.1 and maybe 9.1 is easy and should be done now. 9.1.4 as well, it's fairly common as far as spatial systems are concerned.
• Using ORing flags should yield a better API in the end