Bug 113274
| Summary: | ScriptProcessorNode should block when being rendered in OfflineAudioContexts | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Russell McClellan <russell.mcclellan> |
| Component: | Web Audio | Assignee: | Nobody <webkit-unassigned> |
| Status: | UNCONFIRMED | ||
| Severity: | Normal | CC: | aldel, brad, crogers |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
| Bug Depends on: | 113121 | ||
| Bug Blocks: | |||
Russell McClellan
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
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
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 :-).