Support default arguments for the Web Audio backend

[ehsan]

This patch fixes a DOM error that is generated when the default Sink() constructor is called, which is caused by passing undefined values to createJavaScriptNode. Basically we need to first call the start function, and then read the requested values from the self object.

[jussi-kalliokoski]

Thank you Ehsan!

However, I'm a bit hesitant to pull this in, as the Web Audio API is in a very unstable state right now. More details here, but the gist is that the createJavaScriptNode's argument ordering may change, or the buffer size argument may be dropped, both of which would lead to a horrible sonic experience and possibly very high CPU usage. Then again, now it looks very likely that support for audio processing in the main thread will not be supported at all (Mozilla and Opera representatives are very strongly against main thread audio processing being possible, while I've been trying to defend it with cases such as emscripten in my mind... Maybe it would be useful if you could voice your opinion on the matter?).

Anyway, I wanted to wait until this goes to stable, but it doesn't look like it's happening any time soon, so I think I'm going to merge now.

[jussi-kalliokoski]

Oh, and for the record, here's a link to the discussion/issue on the Audio WG: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415

[ehsan]

Thanks for pulling this! FWIW, this patch was about not passing undefined to the API. Even if the ordering of the parameters change, I don't think passing undefined would work. ;-)

I read the whatwg bug, and I think I agree with roc. We (browser vendors and developers) are still being bitten by synchronous XHR. There are just too many web developers who are not familiar with what blocking the main thread means for their application, and I personally agree that doing any audio processing on the main thread is a recipe for failure. Roc's suggestion of providing canvas access to workers is something that has been discussed with game developers for quite some time, and they seem to like it. And that would be awesome for things like Emscripten too, since you can just execute all of your code on the worker, and the UI will not be blocked, ever!

If you have specific concerns not covered in that discussion or the replies, please let me know. :-)

[jussi-kalliokoski]

Thanks for pulling this! FWIW, this patch was about not passing undefined to the API. Even if the ordering of the parameters change, I don't think passing undefined would work. ;-)

No, thank you for pushing. ;) Yes, I'm well aware, but if it were still passing undefined as arguments, and the argument ordering changed, it would just not work, instead of producing terrible results. Say the buffer size became the last argument, as it is now, after the changes, it would try to create a JSNode with a buffer size of two, and 4096 input channels, which would result in a highly unstable system that would make a lot of glitchy sounds and possibly even freeze the browser.

Yes, I agree that there is no need for main script audio access if workers will have graphics access as well. That's why I'm very sad to see Roc's MediaStreams Processing API abandoned by the group, as it would have catered both of these needs, as well as other use cases...

[charlieroberts]

The callback function passed to Sink does not get called in OS X under Chrome Version 20.0.1132.47 (which now the stable release version). I don't get any errors, but no audio is generated using the tests in the repo; inserting some log statements show the callback function is not triggered.

Has anybody had success with this in the current stable copy of Chrome or Chromium?

[malkomalko]

I can confirm the same problem in the same latest build of chrome charlie

[MiracleBlue]

I can also confirm. Tested just now :( Argh.

[jussi-kalliokoski]

Hmm, the onaudioprocess event never gets fired for some reason, I hope they haven't yet disabled main thread audio processing. I'll try to read if there are some changes in the spec regarding this and then the webkit changelog.

[jussi-kalliokoski]

Fixed per b5b15e6d2defb52d6e9153b6e086df7182a86639. I forgot that the new syntax also requires you to specify input channels even when there are none...

[charlieroberts]

That fixes it for me. Thank you for debugging that... an interesting syntax choice for sure :)