Re: "Layering Considerations" issue

On Thu, Jul 25, 2013 at 6:35 PM, Alex Russell <>wrote:

> On Friday, July 26, 2013, Robert O'Callahan wrote:
>> Does ctx.createMediaElementSource(n) disconnect the output from the
>>> default context?
>> In Gecko, it actually does, because that seems to be what people will
>> usually want. However nothing in the spec says it should, so I think that
>> should be a spec change. It's easy to fix our behavior if we decide not to
>> take that spec change.
Actually, I read the sentence "As a consequence of calling this method,
audio playback from the HTMLMediaElement will be re-routed into the
processing graph of the AudioContext." in the spec as defining that
behavior - "re-routing" - but I guess you're right, that could be a bit
less ambiguous.

> Eliminate MediaElementAudioSourceNode and instead re-cast media elements
>>> as possessing MediaStream audioStream attributes which can be connected to
>>> AudioContexts
>> This is close to what we implement in Gecko.
> Good to hear!

>> We have extended media elements with mozCaptureStream and
>> mozCaptureStreamUntilEnded methods (sorry about the prefixes, they predate
>> the new policy) which return new MediaStreams. (I think returning new
>> streams is a more robust design than having one intrinsic stream that all
>> users of an element must share; also, as discussed above obtaining a
>> MediaStream disables regular audio output, which as a side-effecting
>> operation is not suitable for an attribute getter.)
>> MediaElementAudioSourceNode is just a thin wrapper around
>> MediaStreamAudioSourceNode taking the result of mozCaptureStream.
> From a spec perspective, it's hard to see why both persist then.

Because of that side effect, I would expect.  I suppose we could split
along the lines ROC implies here - have a "getStream" on <audio> that
disables normal output.  I expect at the time we were being sensitive about
the need to edit the HTML5 spec, rather than the Web Audio API being more

Is that context available to script? Is there such a thing as a "default
>>> context"?
>> No, and no.
> I agree with the first, but not the second. It's observable in
> implementations that there is a default context.

It's observable in implementations that there is a context (if you
presuppose correct layering, rather than be historically informed :)) that
<audio> and <video> are attached to by default.  I'm not sure that's the
same thing.


Received on Friday, 26 July 2013 16:05:59 UTC