Does anyone have a good handle on what the GPL means in the context of a javascript library invoked by an html page rendered by a browser? I certainly don't!

nb, you say: "libmad has commercial license. As for jsmad, we're in a sort of grey legal area." I presume you mean that you would have problems with a commercial licence? Your work is clearly a derivative work of libmad, so it has to be GPLv2 licensed: any commercial license would have to be by agreement with the libmad developers I think.

Regardless: very cool stuff!

Yes, anything under the GPLv2 is obviously fine. But we cannot relicense it under a commercial/liberal license like libmad could (at least not without their permission).

That's my take too.

The remaining question then is just how far the reach of the GPL is in the context of a javascript library. Just the javascript that actually calls the code? Everything else called from the same html page? Everything else on the same site?

It's a shame the history of libmpg123 is so clouded: they've made a good effort to contact all the previous developers to get permission to LGPL the library, but they haven't been able to reach everyone so there are always going to be lingering doubts.

Yes, we would love to discuss commercial license with the Underbit/libmad guys. So if you're here, hello! Let's talk :)

Here too, and please send us a tweet or so if you make something cool with it!

It seems to stutter if you change tabs, is this due to restrictions in Firefox background tabs and timers?

Edit: Awesome stuff, btw :D

jsnockert's reply to this is dead for some reason:

---

jensnockert 3 minutes ago | link [dead]

The stuttering when in a background tab we think is related to timers yes, but we hope that properly buffering the audio will fix it.

-----

The answer to this is complex, and I've spent the last night tuning the player so that it wouldn'd do that.

There are several scenarios here:

1) Either the MP3 data buffer doesn't fill fast enough (slow network transfer), so when it runs out of buffer, all hell breaks loose. This is because player.js is really naive, so more a demo bug than a jsmad bug.

2) Or Firefox fails to call the scheduled tasks (via setTimeout) for more than the length of a sound buffer, and then the audio device just stops. If the audio device stops updating for more than 500ms, player.js just resets the audio device and tries again.

3) And worst case: something goes really wrong, the rebuffer is called but audio is no longer being played. I have no idea what happens here, I'm laying the blame somewhere between Firefox 4 and audiolib.js (which is awesome btw).

So yeah, apparently browsers are really bad at scheduling CPU and IO-intensive concurrent things. It shows when streaming a large file - been listening to 1h+ mixes, which works, but stutters a lot in the beginning.

Just giving the mozilla devs a good benchmark to optimize for :)

From the Firefox 5RC1 release notes:

> Background tabs have setTimeout and setInterval clamped to 1000ms to improve performance

As far as I'm aware, Chrome does this also but I'm not sure what version it was introduced in.

If we could find a way to increase the audio buffer size in audiolib.js (the refill buffer it's giving us pretty small although we have a big preBufferSize) it'd probably be enough.

Did you intentionally take a stab at Atwood's law?

I'll dig up the mathematician in me and answer to a generalized version of this question:

"Are you aware that this is probably one of the most inane use of Javascript and did you do it to piss people off?"

To both questions the answer is: Yes, absolutely.

I think this is the beginning of something beautiful.

On Chrome 13 if you enter a new ID track and hit enter it will keep playing the old song even if you start playing the new one or it will have that crkkkk repeating sound. :) Firefox 4 seems to have no problem but you have to sometimes hit refresh and then play to get the new track playing.

One cool feature would be to make a random ID track generator so you won't have to search/enter the codes for yourself.

Hope this feedback helps somehow.

Did I say how cool all this is?

Thanks for the feedback, jaquis!

Re: Chrome 13, I haven't had a chance to test this myself, but I suspect that dev.kill() doesn't work as expected then :/ if it's a Chrome bug that would really suck cause it wouldn't be the first one.. see http://code.google.com/p/chromium/issues/detail?id=82795 (seriously Google Chrome team, get your stuff straight!)

Re cool feature: actually, we had in mind using the Official.fm Simple API (see http://official.fm/developers/simple/ for more infos) to add a Search feature. As an official.fm dev, though I'm warning you: our search system is undergoing serious refactoring and the current system has lots of... room for improvement, put politely.

Thanks again for your time!

While I'm at it, I forgot to say this, but: if you have MP3s that don't play, please upload them on Mediafire and submit a Github bug report: https://github.com/nddrylliog/jsmad/issues - you'd be surprised how quick we can figure out, after collectively spending 300+ hours debugging the code :)

o/

Hey dude :) Long time no see. As you can see, I've moved on t greener pastures ;)

(I also happen to be the author of http://ooc-lang.org/, and that's where I know gmaster1440 from)