demo · v152 · media capture

Preferred Capture

Click capture to run a real getDisplayMedia() call that asks for audio and adds the audioSelection: "preferred" hint. The page then reports the audio track the user agent actually attached — its label, getSettings(), and a live level meter — so you can see whether audio came along.

Experimental preference hint. audioSelection is a dictionary member — you still choose in the picker. To test Chromium's runtime-gated implementation, use a suitable Chrome build and open chrome://flags/#enable-experimental-web-platform-features and set Enabled, or launch Chrome with --enable-blink-features=GetDisplayMediaAudioSelection (or --enable-experimental-web-platform-features). Unrecognized dictionary members do not make the call reject, but this page cannot determine whether audioSelection was recognized. It reports the observable outcome (did the user-mediated capture return an audio track?), not a claim that the hint caused it.
probing getDisplayMedia…
no capture yet
No capture yet.

the call

const stream = await navigator.mediaDevices.getDisplayMedia({
  video: true,
  audio: true,
  audioSelection: "preferred"   // NEW in 152 — prefer capturing audio too
});

const audio = stream.getAudioTracks()[0];
console.log(audio ? audio.getSettings() : "user shared video only");

The sole current AudioSelectionPreferenceEnum value is "preferred". The incomplete Editor’s Draft says it signals that the application would like the user agent to steer the user toward sharing audio; the user agent may ignore it. It does not override user choice or apply audio constraints (those still live in audio).

see also