Burgestrand/Hallon — Issue #59: Audio support
Author: Burgestrand
Created: 2011-12-01 12:04:12+00:00
State: open
Labels: Feature Request

Streaming audio is already possible through Hallon, although it’s a bit clunky. Once the callback system has been revamped (#56) we should be one step closer to full audio support (that includes *playing* audio).

I’ve previously done a proof-of-concept audio player with Hallon and Ruby, using the libspotify jukebox example code. It’s written using the OpenAL audio driver and is only supported on Mac OS X systems. It’s unstable, might leak memory, has audio stutters and only support playback once… but it ***can** play some frickin’ music*!

There is no way I’m just taking that code and incorporating it into Hallon, however. It needs to be thoroughly cleaned up. If you wish to have a look at it, here it is: https://gist.github.com/e55c9c7de9792f7c818e. I **will not** support or maintain this particular proof-of-concept code. It was written solely to see if audio playback was even possible. It is.

For minimal audio playback support, Hallon will need:

1. way better callback handling (see #56)
2. a way of streaming audio to an audio driver (related to #56, but it is its own issue)
3. streaming audio drivers for chosen platform, openal is one, and they must support some way of feeding audio to them

There is a possibility that issue number three, and at least parts of issue number two, will need to be written in C. For one, Ruby’s stop-the-world GC might cause issues and glitches in audio playback. In addition, the GIL means that sometimes Ruby mightn’t even have time to handle audio streaming before it’s too late. As I’m writing this, I ponder if/how the pyspotify guys have solved this issue.

Anyway, dropping down to C threading might be the way to go, and handle the audio callback and playback outside of Ruby land. We’d still need some ways to communicate with the audio playback thread, though. Making it start/stop/pause and query it for buffer sizes and whatnot.

PS: this issue is more like a milestone. Unfortunately, GitHub does not support multiple milestones for one issue, so we’ll have to label related tasks with the Audio label.