910045 - ScriptProcessorNode onaudioprocess sometimes fires too fast

Status: RESOLVED INVALID

(Core :: Web Audio, defect)

Description

[Michael Lelli]

Attachment: 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.

Comment 1

[Manuela Muntean [Away]]

Attachment: 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!

Comment 2

[(no longer active)]

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!

Comment 3

[Michael Lelli]

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.

Comment 4

[(no longer active)]

(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?

Comment 5

[Michael Lelli]

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.