webkit audio not detected correctly? about audiolib.js

[jussi-kalliokoski]

i could get grunt to build audiolib (keeps saying that grunt.js is not found)

Yeah, the current stable version of grunt uses grunt.js for a config file, but this will be changed in 4.0.0 to Gruntfile.js. I'm already using that to keep things working under Windows as well (cmd.exe is a PITA). If you're using <4.0.0 of grunt, you should use this flag --config Gruntfile.js to keep things working nicely. Personally I have alias grunt="grunt --config Gruntfile.js" in my .bashrc. :)

could we have the latest build file in git too?

I used to have it that way, but it started to be a lot of noise in the version control. :/ I'm considering it, but we'll see.

I'll have to check out Chrome Canary later today to see why this is happening, I'll see what I can do. :)

[zz85]

thanks for looking into this. i've double checked the sink.type in canary and it now gives "wav". nevertheless in the wave fallback, could it be a good idea to remove/delete wav that have been inserted so that memory would not be overloaded?

somehow i think my grunt configuration is wrong because it now complains grunt-pack is not found. :( perhaps a suggestion for the build file is to put it into its own build folder so its easier to isolate build changes when you git diff the source folder.

[zz85]

okay, i think i've managed to narrow down the problem. when sink is trying to initialize the canary webkit audio in the block

for (i=0; i<sinks.length; i++) {
        if (sinks[i].enabled) {

the following error is thrown...

DOMException
code: 12
message: "SYNTAX_ERR: DOM Exception 12"
name: "SYNTAX_ERR"

[jussi-kalliokoski]

Okay, I managed to track down the problem. It's because the syntax for AudioContext:createJavaScriptNode() has changed. I contacted Chris Rogers to see if there's a way to make the syntax more lenient to avoid breaking a lot of demos depending on sink.js out there. If not, I'll just fix this on sink.js's somehow and hope people will update.

it now complains grunt-pack is not found

Try npm install grunt-pack paramon script-builder, that should equip you with all the packages needed by the build commands. I'll see if I can make it clearer in the build directions.

perhaps a suggestion for the build file is to put it into its own build folder so its easier to isolate build changes when you git diff the source folder
All the generated files are in the ./lib/ folder and I had that directory as a part of the repo for a long time, but it was still a lot of noise :/ I'll keep thinking about this.

[zz85]

on narrowing down the problem, it seems that

node        = context.createJavaScriptNode(bufferSize, 0, channelCount),

is throwing the error. for some reasons, chrome 18 allowed bufferSize and channelCount to be undefined, but not in canary 20.

[zz85]

ah. just saw your message. cool, hopefully things will work out either way. thanks for the build suggestion, i'll try that.

[zz85]

somehow using the -g to install those didn't. but npm install grunt-pack paramon script-builder works. :)

[jussi-kalliokoski]

Yeah, -g installs the packages to /usr/lib/node_modules for use of executable npm packages, those packages aren't directly available via require(), -g should only be used when you want to install something executable :)

[jussi-kalliokoski]

Sorry for the long wait on this.

I've discussed this with Chris Rogers and on Audio WG and I decided that I won't change anything just yet, because the Web Audio API is likely to change heavily soon. If this will land on stable, I'll change my stuff. But for now if I fixed it, it would be subject to breakage if the API is changed, and it probably will be. And by breakage, I mean that it's possible that if I fixed it, we would allocate 2048 input channels for the JavaScript node, quite possibly making pages relying on this completely unusable. :/

Keeping it open anyway. :)

[mauro7inf]

audiolib.js user here (offtonic.com/synth). It looks like whatever the issue was with Chrome 20 is there for good; Google just released their Moog doodle's source code with a mention of the Web Audio overhaul, and now my synth no longer runs smoothly in Chrome! It clicks every half a second or so, with that much latency. Is this part of the same issue or do I just suck at coding?

[jussi-kalliokoski]

Yes, it's part of the issue, and nope, it's not your fault! I forgot to update audiolib.js to use the fixed version of sink.js, but now it's done, so please update your version of audiolib.js. :)

[mauro7inf]

Thanks for doing that! However, it seems that it's still not detected correctly on today's new update. The sound clicks every half a second or so in Chrome, as I mentioned, but as it turns out, that half a second figure is exact: line 3508 of audiolib.js contains that 22050 number. When I take away that 0, the clicks make a nice tremolo effect, which is annoying but at least less so than half-second latency! (And I can play Tárrega on my synth. ;p) Firefox used to have this problem several months ago but no longer does (though performance is still much slower than Chrome).

From what I can tell, this is in the sink class for WAV data URLs, which shouldn't be the case since I'm supposedly using Web Audio. I guess this means that it's not detecting my browser for some reason, given the previous comments on this thread.

[jussi-kalliokoski]

Wohooops, build process fail, I forgot to update the local version of sink.js instead of just pulling the latest version of the repo, sorry. -.- Should be fixed now...

[mauro7inf]

Thanks, there we go! By the way, maybe I'm stupid, but it's possible that the .tar.gz has this morning's version without the new sink.js and the .zip has the correct version. Either way, everything's in good working order now -- thank you for building and maintaining audiolib.js!

(Oh, I forgot -- this is what your work is being used in:

http://offtonic.com/synth

Microtonal synthesis is fun!)

[jussi-kalliokoski]

The .tar.gz looks fine to me, but could be that GH had some caching going on as I overwrote the files with the same names.

Microtonal synthesis is indeed cool! Looking to find more time to play around with your synth soon, looks way sweet!