Re: "Layering Considerations" issue

On Thu, Jul 25, 2013 at 6:35 PM, Alex Russell <slightlyoff@google.com>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
self-contained.

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.

-C