Audio Hardware and Configuration Data

[AdamSobieski]

Hello. This issue is about providing end-users with opportunities to make available more information about their audio hardware and configuration data, in particular for DASH-related audio track selection algorithms. So doing would enable high-end, device-tailored audio experiences to be created and delivered.

End-users could be provided with opportunities to opt in to share more information about their particular audio hardware and configuration data. This data might include information about their devices, e.g., smartphone manufacturers and models, and/or about their specific speakers.

With directly provided and/or inferable audio hardware data (e.g., speakers' sound profiles and frequency response data) music producers and audio engineers would be able to optimize versions of songs (or videos' audio tracks) for playback both on categories of audio hardware (e.g., Dolby Atmos, 7.1 surround, 5.1 surround, television speakers, soundbars, computer speakers, subwoofers, smartphone speakers, headphones, and earbuds) and for specific devices and speakers.

As envisioned, end-users’ computing and home-entertainment devices, e.g., smart televisions, would then be better able to automatically select the finest audio experiences from available options.

End-users being able to opt in to and out of providing their audio hardware and configuration data is intended as a means of addressing some of the concerns raised in issue #176.

Resembling issue #43, end-users' provided audio hardware and configuration data might be dynamic during streaming and playback. End-users could change their selected audio output devices and configuration data during playback, e.g., by plugging in or removing Bluetooth earbuds or other headphone devices.

Thank you, I look forward to discussing these ideas with you.

[chrisn]

Related issue: #73. We discussed briefly in the Media WG meeting 12 December 2023 (minutes).

For video, Media Capabilities answers questions about the browser's ability to decode, rather than render the media. But for audio the API includes both. I think we need to discuss whether that's still the approach we want or if audio rendering capabilities should be exposed elsewhere.