demo · v141

Music App Screencast

A web-based DAW or music player wants users to record their screen for a tutorial — playing the app's own music. restrictOwnAudio: true would silently kill the audio you're trying to demonstrate. Some apps want to include their own audio explicitly. This concept shows the inverse case and how to detect what the platform actually delivers.

checking support…
Tutorial Beat — track 01a demo loop you'd play while screencasting
no capture yet

the contract is a hint — verify settings

const stream = await navigator.mediaDevices.getDisplayMedia({
  audio: { restrictOwnAudio: false },
  systemAudio: "include",
});

const settings = stream.getAudioTracks()[0]?.getSettings();
if (settings?.restrictOwnAudio !== false) {
  // Platform refused the hint. Surface this to the user — they may need
  // headphones or a separate audio routing solution.
  showWarning("This OS / Chrome build cannot include this tab's audio in the capture.");
}

why this angle

The explainer spends most of its space on the "exclude own audio" case (tutorial recording) but flags that some apps want the opposite — they ARE the audio source, the whole point of capture is to record what this tab is producing. The boolean direction matters and getSettings() is the only honest way to confirm the platform did what you asked. This concept covers the "include own audio explicitly" half of the API and the verification pattern.

see also