v152 · media capture · behind a flag

audioPreferred capture in getDisplayMedia API

A new audioSelection member on DisplayMediaStreamOptions lets a screen-sharing app hint that it would prefer audio alongside video. Its only current value is "preferred". The incomplete Screen Capture Editor’s Draft says this may steer the user toward sharing audio, but the user agent may ignore it and the user still chooses.

concepts

  1. Preferred Capture

    The real call: getDisplayMedia({ video, audio: true, audioSelection: "preferred" }). After explicit user selection, it reports any returned audio track, settings, and live level. Track presence proves audio was returned, not that this non-detectable hint caused it.

  2. Hint vs Default

    Run two separately user-mediated captures — one with audioSelection: "preferred", one without — and record what each returned. The result is observational: different user choices, sources, or OS state prevent a single pair from establishing causation.

  3. Options Inspector

    Build the DisplayMediaStreamOptions object by toggling audioSelection alongside its siblings — systemAudio, windowAudio, monitorTypeSurfaces — see the exact JSON that gets passed, then run it. Explains why a dictionary hint can't be feature-detected in JS and how to degrade honestly.

why the hint exists

Apps that record or stream a screen — tutorials, remote support, presentation capture — may want accompanying audio, but audio: true does not guarantee an audio source will be offered, selected, or returned. audioSelection: "preferred" expresses intent to steer the user toward sharing audio while preserving unrestricted source choice and active consent. Because it is a WebIDL dictionary member, an implementation that does not recognize it ignores that member rather than rejecting for that reason; capture can still reject, stall at the picker, or return video only for other reasons.

Availability, per the ChromeStatus API (updated 2026-07-22): the v152 milestone listing places this feature in two categories at once — Enabled by default and In developer trial (Behind a flag) — while the feature detail gives desktop 152 with status text “Proposed”. Chromium IDL gates the member behind experimental runtime feature GetDisplayMediaAudioSelection, depending on GetDisplayMedia. In the unflagged Chrome 150 review environment, dictionary acceptance and a pending picker could not establish whether the hint was recognized or ignored. Even where implemented, it remains a preference; source capabilities, browser policy, OS support, and user choice determine whether audio is returned.

references