Closed Bug 910045 Opened 9 years ago Closed 9 years ago

ScriptProcessorNode onaudioprocess sometimes fires too fast

Categories

(Core :: Web Audio, defect)

x86_64
Windows 8
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: toadking, Unassigned)

Details

Attachments

(2 files)

Attached file testcase
User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20130827030201




Expected results:

Sometimes the onaudioprocess event for ScriptProcessorNodes fires several times really fast, with less than a couple milliseconds between calls, making my buffer implementation I was making in response to bug 901247 impossible to use.
Attachment #796407 - Attachment mime type: text/plain → text/html
Attached image screenshot.png
Please see the attached screenshot, which is a comparison between latest Nightly (build ID: 20130904030204) and Chrome.

Does anyone have any thoughts/suggestions? Thanks!
Flags: needinfo?
QA Contact: manuela.muntean
Can't you use the event's playbackTime attribute to determine when the output generated by the event is expected to be played back?  There is nothing to guarantee that the event fires at regular intervals, and in fact that is pretty much impossible to implement since we cannot interrupt the main thread at arbitrary times!
Flags: needinfo? → needinfo?(toadking)
The problem is the times where it fires a bunch of times rapidly. If you only prepare for a small amount of playback, this can hurt. In my case, I have a buffer of audio of only about 80ms. Ideally it's only half full, but if the callback gets called 3-4 times in less than 15ms (which is mainly what this bug is for), it drains the buffer and I get audio popping.

My program also does audio rate manipulation to try to keep the buffer at half size as much as it can, so when the buffer suddenly empties it can try to adjust the audio frequency by too much. This isn't really a Web Audio issue though.
Flags: needinfo?(toadking)
(In reply to comment #3)
> The problem is the times where it fires a bunch of times rapidly. If you only
> prepare for a small amount of playback, this can hurt. In my case, I have a
> buffer of audio of only about 80ms. Ideally it's only half full, but if the
> callback gets called 3-4 times in less than 15ms (which is mainly what this bug
> is for), it drains the buffer and I get audio popping.

I think you're making incorrect assumptions here.  ScriptProcessorNode is a pull based API, so you must be prepared to provide the event with as much data as it requests.  Note that the browser may decide to fire a bunch of events early on in order to be able top provide a glitch free playback later on.  Does this make sense?
That makes sense, however it also makes it useless for my usecase. Is there any way to implement audio blocking without busywaits or is this a limitation of Web Audio, or even Javascript's concurrency model?

Anyway if this is intended behavior then I guess this can be closed.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.