demo · v136
Iframe inherits sink
The point of setPreferredSinkId: a top-level frame can route audio for itself and every child iframe — including cross-origin ones — without a postMessage handshake. Set the sink in the parent and watch the iframe's playback adopt it.
parent frame (this document)
child iframe (same origin)
The iframe never calls setPreferredSinkId itself — the parent's choice flows down.
the code
// Parent frame — one call covers all renderers below it.
await navigator.mediaDevices.setPreferredSinkId(deviceId);
// Inside the iframe: no permission ask, no postMessage handshake.
// <audio>.sinkId reads as the parent's chosen device for every renderer
// constructed after the call (existing elements keep their explicit sinkId).why this angle
The sibling concept exercises the basic case — one document, one audio element, set the preferred sink. The explainer's actual motivation though is the cross-origin iframe gap: pre-136, a top-level video conferencing site couldn't make the ads / chat / embedded-doc iframes inside it play to the user's chosen headset. Sites had to ship a postMessage protocol every embedded library opted into. setPreferredSinkId closes that gap; this concept demonstrates the iframe inheritance in one page.