MP3 Streaming Support about audiolet

[oampo]

Waiting for aurora.js to get released before working on this. That should fulfil pretty much all of my streaming needs, and be easier to integrate than mp3.js.

[zz85]

there's also https://github.com/nddrylliog/jsmad too for royalty free mp3 decoding in JS. btw, there's also an updated version of sink.js

[oampo]

Oops - when I said mp3.js I mean jsmad. According to the nice folks behind jsmad (who are also developing aurora.js), jsmad is too tightly coupled to its own buffering and output code to be at all friendly to integrate with Audiolet. aurora.js is designed to fix this (and a whole host of other) issue, so their best advice is to wait.

I pulled the latest sink.js to master though - cheers for the heads-up.

[tambien]

has there been any progress on this issue? i am working on an ambitious multitrack audio player and it is unreasonable to use wavs for everything (4 tracks @ 4:00 each is >100MB).

any progress on aurora.js?

thanks for the great work and the great library.

[oampo]

Still waiting I'm afraid - the ofmlabs folks are busy. You can track progress on aurora.js at https://github.com/JensNockert/aurora.js. As a stopgap you might find something based on https://gist.github.com/1599851 useful. It's Web Audio API only so won't work in Firefox, but if that's not an issue then it will probably work okay. Be warned though that it is pretty hacky and not very well tested, so ymmv.

[tambien]

cool! this is a good start. thanks.

looking through some of the documentation, both Firefox and Chrome support OGG out of the box. it doesn't seem like it would be too much effort to expand your WebKitBufferPlayer into a general "OggBufferPlayer" that could work in both browsers. that would be a really useful shim until the ofmlabs people release their panacean codec library.

[oampo]

@tambien It's actually not quite as simple as that, as the WebKitBufferPlayer code relies on the Web Audio API to do the decoding and streaming. However, the approach of having what is essentially a FIFO buffer in the JavaScript holding (hopefully) enough data that we don't get underrruns may be applicable to the Audio Data API too. In theory you could replace the JavaScriptNode onaudioprocess event with the Audio Data API's mozAudioAvailable event (see https://wiki.mozilla.org/Audio_Data_API#Reading_Audio), and you might have a working cross-platform solution, albeit a very limited, and stupendously ugly one...

If you want to have a go at getting it working I'd firstly try to copy the WebKitBufferPlayer code and swap out the JavaScriptAudioNode for a <audio> element using mozAudioAvailable, and call it something like MozillaBufferPlayer. If that works then you should be able to check the type of sink and use whichever version is appropriate.