- From: Chris Wilson <cwilso@google.com>
- Date: Fri, 26 Jul 2013 09:05:31 -0700
- To: Alex Russell <slightlyoff@google.com>
- Cc: "robert@ocallahan.org" <robert@ocallahan.org>, "public-audio@w3.org" <public-audio@w3.org>, "www-tag@w3.org List" <www-tag@w3.org>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>
- Message-ID: <CAJK2wqWwZhyf4HM6JSiTSbqyk7bZ4PnxkXrYouR7K=Zt40c0cA@mail.gmail.com>
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
Received on Friday, 26 July 2013 16:05:59 UTC