New ways of buffering audio

  • Idea
  • Updated 6 years ago
  • Under Consideration
I'm currently using SoundManager as a new playback option with my Python-based cross-platform HTTP music browsing/streaming server (it's still in a proof-of-concept state, but will be open-sourced if it turns out fine). Desktop players such as WinAmp behave nicely with the backend, buffering ahead only an adjustable amount of data, but the way SM loads tracks fully, even if the listener pauses a track after a few seconds, causes extra burden on the server, especially when someone listens to a track for a while, switches to the next on the playlist, and so on.

Would it be possible to add an option to make SM behave the same way, buffering only n seconds or bytes ahead of the playback position? If not, even an option to pause loading along with playback would help preserve precious bandwidth.

And while we're at it, why not throw in a possibility to setPosition beyond the point of bytesLoaded, making the player load and play data from that position onwards, loading the track piece by piece as requested by the user (HTTP Range requests, anyone)? I understand that VBR would cause some difficulties, but that's why it'd be handy to set the position in bytes, which should be accurate enough for seeking in most cases.

If those buffering issues were solved, the only essential thing missing would be Vorbis audio support (which Adobe is already developing, according to rumors). There has been a lot of discussion on that on the forums of some other Flash-based players, and some mad hacker even wrote a Vorbis decoder of his own!
Photo of Martinique

Martinique

  • 14 Posts
  • 0 Reply Likes

Posted 6 years ago

  • 4
Photo of Scott

Scott, Official Rep

  • 3789 Posts
  • 243 Reply Likes
Official Response
Your ideas are.. sound (zing! :D), but the issue with Flash 8/9 is that with the provided sound API, there is no real way to do bandwidth management or true "streaming" without using some sort of special set-up on the backend eg. Flash + NetStream object requesting sound, via RTMP to Adobe's Flash Media Server (or a free/open-source alternative), to the best of my knowledge. If you watch videos on YouTube, I think the dynamic seek and buffering/loading of video may be achieved with FMS (or something developed in-house, perhaps.)

Additionally, the Flash sound object does not support pausing or resuming of loading, as far as I know. Once a request is started, it will continue until finished. This ties into RAM use, which I'll get into re: Shoutcast/radio streams.

One simple way to perhaps optimize the bandwidth use would be to restrict the server's output, throttling it to 16 KB/sec (or whatever the bitrate of the MP3 is, plus a little bit.)

There have been some developments in this area with Flash 10, and a few people have been working on classes that allow "efficient" streaming from Shoutcast servers, vs. the current method of loading sound which eats more and more RAM over time as Flash holds it all there while the connection is open, and thus requires the sound to be stopped and reloaded every so often so memory will be released. I think SoundCloud may be doing this to support quick seeking within their sounds, which are typically long DJ sets of 30+ minutes.

I do think it might be possible to support seeking within a sound by closing a HTTP request and opening a new one at the new position eg. /mp3/?position=12345, where the server returns a new header and the start of the new data (?), but that would mean server work to be able to support that sort of feature - the client would be rather "dumb" in this case.

Flash 10 also allows for alternate formats to be introduced as you can load, generate and manipulate sound data on the fly (ie., read OGG and decode to raw RIFF/WAVE etc., feed to sound buffer), but it is non-trivial and the native Flash sound API which SM2 is based on (including onload() events, etc.) may be lost unless the developers choose to re-implement those methods.

I have been looking at "as3mp3stream", a class hosted on Google Code, and have a prototype in progress which does allow for streaming from Shoutcast servers (and support for song change events, etc.) It does have some limitations (eg., special cross-domain permissions are required to allow the stream to work), but gives an idea of the sort of dynamic options available.

http://getsatisfaction.com/schillmani...

Good questions and points, I would like to see more of these sorts of features become standard with sound APIs.