Closed Bug 910045 Opened 9 years ago Closed 9 years ago
Processor Node onaudioprocess sometimes fires too fast
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
Please see the attached screenshot, which is a comparison between latest Nightly (build ID: 20130904030204) and Chrome. Does anyone have any thoughts/suggestions? Thanks!
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.
(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?
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.