Bug 83902 – OfflineAudioContext constructor must be exposed for Web Audio API

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Audio

[Chris Rogers]

Internally for our layout tests we use an OfflineAudioContext for offline processing, but this is not yet in the specification.

Currently the layout tests overload the "normal" AudioContext constructor as such:
context = new webkitAudioContext(2, lengthInSampleFrames, sampleRate);

Providing three arguments, then creating an OfflineAudioContext instead of a normal AudioContext.  But to expose this as an official part of the spec, I believe it would be better as:

context = new OfflineAudioContext(2, lengthInSampleFrames, sampleRate); // but of course for now would have the "webkit" prefix  -- webkitOfflineAudioContext

This is because it's a different kind of context and we'll need to be careful that the "normal" AudioContext has room to grow with additional constructor arguments that don't clash with the offline ones...

[Eric Carlson]

If this is just for layout tests, it might be better to add it to the Internals object so it can't be exposed to web content.

[Chris Rogers]

(In reply to comment #1)
> If this is just for layout tests, it might be better to add it to the Internals object so it can't be exposed to web content.

Although it is currently used by layout tests, the idea is to provide an official API for it because it's useful and people have been requesting it on the W3C audio list, for example:
http://lists.w3.org/Archives/Public/public-audio/2012AprJun/0024.html

[Eric Carlson]

(In reply to comment #2)
> (In reply to comment #1)
> > If this is just for layout tests, it might be better to add it to the Internals object so it can't be exposed to web content.
> 
> Although it is currently used by layout tests, the idea is to provide an official API for it because it's useful and people have been requesting it on the W3C audio list, for example:
> http://lists.w3.org/Archives/Public/public-audio/2012AprJun/0024.html

Then we should get it into the spec as soon as possible. 

We should strive to not have web facing API that isn't spec'd because developers will find and use it, which can make it difficult to change things in the future.

[Chris Rogers]

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > If this is just for layout tests, it might be better to add it to the Internals object so it can't be exposed to web content.
> > 
> > Although it is currently used by layout tests, the idea is to provide an official API for it because it's useful and people have been requesting it on the W3C audio list, for example:
> > http://lists.w3.org/Archives/Public/public-audio/2012AprJun/0024.html
> 
> Then we should get it into the spec as soon as possible. 
> 
> We should strive to not have web facing API that isn't spec'd because developers will find and use it, which can make it difficult to change things in the future.

I totally agree.  I've just made a bunch of fixes to the current editor's draft to address list feedback and will be working on it more today and probably Monday.  I hope to present this work to the audio group very soon, hopefully to publish a new working draft.

[Chris Rogers]

Fixed:
http://trac.webkit.org/changeset/137516