4 ms·

jsmad lead developer here, shoot if you have any questions!

by nddrylliog 15y ago

deleted 15y ago
[deleted]
gmaster1440 15y ago
o/
- nddrylliog 15y ago
  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/ http://ooc-lang.org/, and that's where I know gmaster1440 from)
jensnockert 15y ago
Here too, and please send us a tweet or so if you make something cool with it!
- Kudos 15y ago
  It seems to stutter if you change tabs, is this due to restrictions in Firefox background tabs and timers? Edit: Awesome stuff, btw :D
  - jensnockert 15y ago
    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.
  - shrikant 15y ago
    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. -----
  - nddrylliog 15y ago
    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 :)
    - Kudos 15y ago
      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.
      - nddrylliog 15y ago
        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.
pja 15y ago
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!
- jensnockert 15y ago
  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).
  - pja 15y ago
    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.
- nddrylliog 15y ago
  Yes, we would love to discuss commercial license with the Underbit/libmad guys. So if you're here, hello! Let's talk :)
lloeki 15y ago
Did you intentionally take a stab at Atwood's law?
- nddrylliog 15y ago
  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.
jaquis 15y ago
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?
- nddrylliog 15y ago
  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 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/ 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 https://github.com/nddrylliog/jsmad/issues - you'd be surprised how quick we can figure out, after collectively spending 300+ hours debugging the code :)

jsmad lead developer here, shoot if you have any questions!

deleted 15y ago

[deleted]

gmaster1440 15y ago

nddrylliog 15y ago
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/ http://ooc-lang.org/, and that's where I know gmaster1440 from)

jensnockert 15y ago

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

Kudos 15y ago
It seems to stutter if you change tabs, is this due to restrictions in Firefox background tabs and timers? Edit: Awesome stuff, btw :D
- jensnockert 15y ago
  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.
- shrikant 15y ago
  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. -----
- nddrylliog 15y ago
  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 :)
  - Kudos 15y ago
    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.
    - nddrylliog 15y ago
      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.

pja 15y ago

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!

jensnockert 15y ago
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).
- pja 15y ago
  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.
nddrylliog 15y ago
Yes, we would love to discuss commercial license with the Underbit/libmad guys. So if you're here, hello! Let's talk :)

lloeki 15y ago

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

nddrylliog 15y ago
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.

jaquis 15y ago

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?

nddrylliog 15y ago
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 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/ 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 https://github.com/nddrylliog/jsmad/issues - you'd be surprised how quick we can figure out, after collectively spending 300+ hours debugging the code :)