WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
UNCONFIRMED
Bug 113274
ScriptProcessorNode should block when being rendered in OfflineAudioContexts
https://bugs.webkit.org/show_bug.cgi?id=113274
Summary
ScriptProcessorNode should block when being rendered in OfflineAudioContexts
Russell McClellan
Reported
2013-03-25 21:52:30 PDT
The purpose of OfflineAudioContext is nominally to be able to "mix down" web audio sessions into a single audio buffer. However, the current behavior with ScriptProcessorNodes isn't useful: steps to reproduce: 1) create OfflineAudioContext 2) create sine wave generator ScriptProcessorNode, attach to destination 3) attach an oncomplete and start rendering the offline audio context wanted result: The ScriptProcessorNode is called several times, creating a clean sine wave in the final buffer. actual result: the offline audio context renders at full speed on the audio thread, not blocking for the Script Processing on the main thread. If the main thread isn't done by the time audio is needed, that buffer is dropped. If you're lucky, a few buffers of sine wave here or there will get mixed down. While the current behavior doesn't directly violate the spec, it does seem like it's neither useful nor intended. I mentioned this to the public web audio list here:
http://lists.w3.org/Archives/Public/public-audio/2013JanMar/0396.html
But it seems there wasn't agreement that the current behavior was allowed by the current spec. I have a patch for this (I simply added a condition variable to ScriptProcessorNode that is waited on during offline rendering) but it depends on
https://bugs.webkit.org/show_bug.cgi?id=113121
Attachments
Add attachment
proposed patch, testcase, etc.
Chris Rogers
Comment 1
2013-03-25 22:02:00 PDT
Sounds fine. It's ok to synchronize with the main thread if it's an OfflineAudioContext (but not for the normal real-time AudioContext).
Russell McClellan
Comment 2
2013-03-26 08:16:59 PDT
Yeah, my patch doesn't affect the realtime case at all. As I said, I'm waiting to add a patch because I was working on top of the patch I made for
https://bugs.webkit.org/show_bug.cgi?id=113121
As a complete newcomer here, I don't really have a sense for how long patches like that take to go through, or really any sense of what the process is supposed to be. Let me know if there's anything I can do to expedite the process or any protocols that I missed :-).
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug