This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 18334 - Asynchronous write
Summary: Asynchronous write
Status: CLOSED INVALID
Alias: None
Product: AudioWG
Classification: Unclassified
Component: Web Audio API (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: TBD
Assignee: Chris Rogers
QA Contact: public-audio
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-19 16:18 UTC by Jussi Kalliokoski
Modified: 2012-10-24 09:16 UTC (History)
1 user (show)

See Also:


Attachments

Description Jussi Kalliokoski 2012-07-19 16:18:42 UTC
I may be wrong, but it seems to me that currently the JavaScriptNode has no way of filling the buffers asynchronously. I suggest we adopt the way that Robert's proposal did the callbacks, having a write method on the event. Allowing asynchronous writes makes sense in an environment like JS where most of the external operations are asynchronous. Also, for example if we define a DSP library that supports things such as convolution, it would be ideal for it to provide asynchronous versions of the calls as well, to make it more natural to the async flow of JS programs, not to mention that you could do concurrent overlap-add things. So for example (very simplified):

var l = 2048

customNode.onaudioprocess = function (e) {
  var buffer = new Float32Array(l)

  oscillator.fillBufferAsync(buffer, function () {
    e.writeAudio(buffer)
  })
}

This would also allow one to write data ahead of time.
Comment 1 Chris Rogers 2012-10-05 20:23:32 UTC
I think we effectively already have an async write() in AudioBufferSourceNode.start()
Comment 2 Jussi Kalliokoski 2012-10-05 22:32:13 UTC
(In reply to comment #1)
> I think we effectively already have an async write() in
> AudioBufferSourceNode.start()

That's not suitable for continuous asynchronously generated audio, but this feature is actually probably better off as custom JS buffer handling. Closing.
Comment 3 Olivier Thereaux 2012-10-24 09:16:46 UTC
Seeing no objection to the resolution as invalid in over 2 weeks, closing.