Closed olivierthereaux closed 7 years ago
On 4/1/15 the group agreed on adopting the 2nd approach outlined in Chris Wilson's draft of the AudioWorker specification, in which AudioContext.createAudioWorker() returns a Promise
Bravi, that is very beautiful. N.
On 15 Apr 2015, at 16:28, Joe Berkovitz notifications@github.com wrote:
On 4/1/15 the group agreed on adopting the 2nd approach outlined in Chris Wilson's draft of the AudioWorker specification, in which AudioContext.createAudioWorker() returns a Promise, which completes after the script is loaded and has run. When the Promise has succeeded, the AudioWorker is ready to use with no script-induced delays. All node configuration can take place within the worker script. onnodecreate and onaudioprocess event handlers are shared among all node instances; the passed-in event in both cases has a "node"property that refers to a audio-worker-side node handle object.
— Reply to this email directly or view it on GitHub https://github.com/WebAudio/web-audio-api/issues/113#issuecomment-93422601.
It is giving us a hard time not to know what is behind the curtain. I am regularly checking this group and chrome-status https://www.chromestatus.com/features#AudioWorker and it feels like there has been made some decisions but the development has not yet started. The first time I asked was in September 2014 where I got the response: "soon"
AudioWorkers are crucial for our development in audiotool.com. Especially when dealing with the web-midi-api. Lower latency and increasing playback stability are the key-points we are looking forward to.
Is there any place where I can get more recent information? Any insights are appreciated.
@andremichelle the group adopted the AudioWorker spec changes 4 weeks ago, so the path is not in doubt. That is actually a big change since Sept. 2014 at which point we did not have an agreed specification for AudioWorker. The whole WG understands that AudioWorker is crucial for adoption of Web Audio and unfortunately it took a while to hammer it out.
Actual implementation progress is a matter for the individual browser vendors to answer; I'd recommend asking on public-audio-dev@w3.org (because this particular group's all about the specification).
@joe, @andremichelle, in light of #532, the spec still needs some work to be implementable, but I'm optimistic, those new issues are technical spec/Web Platform issues, we should be able to solve them quickly, since we all more-or-less agree on the API and on the behaviour.
@joeberkovitz I did not expect it to be an easy task. However it feels from the outside that there are way too many people interfering with the outlines of the possible implementations. I am not sure if this way of having discussions all over this github place is a good way to approach a good solution. In any case it seems very slow. Forgive my naiv attitude. I am sure you guys take it all very seriously.
Out of interest: The post before mine is from May. Is there anything going on in another thread I am missing?
@andremichelle: yes, https://github.com/WebAudio/web-audio-api/issues/532 and http://www.w3.org/2015/07/09-audio-minutes.html#item04 (a bit down the page)
Hi André,
We're actually waiting on @padenot right now to write up the proposal, which has been fairly settled for some time (although #532 shook things up a little bit after we thought it was well understood). So I'm glad to report that this issue is not dangling waiting for further community input. It's waiting to be specified.
...Joe
On Tue, Jul 21, 2015 at 7:09 AM, André Michelle notifications@github.com wrote:
Out of interest: The post before mine is from May. Is there anything going on in another thread I am missing?
— Reply to this email directly or view it on GitHub https://github.com/WebAudio/web-audio-api/issues/113#issuecomment-123263992 .
. . . . . ...Joe
Joe Berkovitz President
Noteflight LLC 49R Day Street / Somerville, MA 02144 / USA phone: +1 978 314 6271 www.noteflight.com "Your music, everywhere"
Thanks for the insides Joe, I really appreciate it.
Any updates on this?
— André Michelle
On 21 Jul 2015, at 16:39, Joe Berkovitz notifications@github.com wrote:
Hi André,
We're actually waiting on @padenot right now to write up the proposal, which has been fairly settled for some time (although #532 shook things up a little bit after we thought it was well understood). So I'm glad to report that this issue is not dangling waiting for further community input. It's waiting to be specified.
...Joe
On Tue, Jul 21, 2015 at 7:09 AM, André Michelle notifications@github.com wrote:
Out of interest: The post before mine is from May. Is there anything going on in another thread I am missing?
— Reply to this email directly or view it on GitHub https://github.com/WebAudio/web-audio-api/issues/113#issuecomment-123263992 .
. . . . . ...Joe
Joe Berkovitz President
Noteflight LLC 49R Day Street / Somerville, MA 02144 / USA phone: +1 978 314 6271 www.noteflight.com "Your music, everywhere" — Reply to this email directly or view it on GitHub https://github.com/WebAudio/web-audio-api/issues/113#issuecomment-123346650.
Seems like there was a conversation about this in the mailing list in the last couple of days.
https://lists.w3.org/Archives/Public/public-audio/2015JulSep/0047.html
Where? I'd like to contribute.
Ah! I guess you're subscribed by email. I updated my previous comment with the link. But here you go.
https://lists.w3.org/Archives/Public/public-audio/2015JulSep/0047.html
@andremichelle et al., there is some substantial and very recent progress here to report.
@padenot is in the process of writing up a more detailed proposal which can be viewed on an ongoing basis here: http://padenot.github.io/web-audio-api/ The first step of this work is refining the asynchronous processing model in Web Audio so that the descriptions of AudioWorker rest on a very solid foundation.
Paul is transitioning to work nearly full time on this between now and W3C TPAC (October 26) and has committed to a complete spec draft being available by that date.
There's no expectation that any of this will be implemented by TPAC, but this feature is among the very highest-priority tasks of any work taking place in the Audio WG and we're all hopeful of implementations to follow once the spec is agreed.
edit: wrong issue number I posted to.
Hi guys. Regarding the AudioWorker spec, I'm curious to know where things stand at this point in time. Seeing as this issue is still open am I right to assume the spec has not been finalized yet?
We are currently reviewing @padenot's refinement of the processing model mentioned in my previous comment (and it's on the WG's agenda for today's call). A lot of work has taken place on that, and it touches many parts of the specification. The AudioWorker interfaces themselves have not changed much since the original proposal.
Hi, In the spec, AudioWorker.addParemeter() and AudioWorkerGlobalScope.addParameter() should return AudioParam but I think it is a member of AudioWorkerNode and may be not yet created.
Any update on the work being done here?
@Maushundb Take a look at the current proposal.
I don't know what to do with this. @hoch has done a lot of work on worklets and a lot of the text is in the spec already, so I suppose I can close this.
Audio-ISSUE-107 (JSWorkers): JavaScriptAudioNode processing in workers [Web Audio API]
http://www.w3.org/2011/audio/track/issues/107
Raised by: Marcus Geelnard On product: Web Audio API
https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#JavaScriptAudioNode
It has been discussed before (see [1] and [2], for instance), but I could not find an issue for it, so here goes:
The JavaScriptAudioNode should do its processing in a separate context (e.g. a worker) rather than in the main thread/context. It could potentially mean very low overhead for JavaScript-based audio processing, and seems to be a fundamental requirement for making the JavaScriptAudioNode really useful.
[1] http://lists.w3.org/Archives/Public/public-audio/2012JanMar/0225.html [2] http://lists.w3.org/Archives/Public/public-audio/2012JanMar/0245.html