One interesting way of doing it would be to split the audio backend from the player. But it would need some rework to implement a plugin approach where Lightspark would query a directory of plugins, if one is found, to ask what it is, if it implements a sound backend and gives lightspark all it needs to play audio correctly (according to a pre-determined communication API between the binary and the plugin to make sure both can communicate correctly and implement the needed stuff on each side), then list it in the different backends available. One could create a plugin for alsa, pulseaudio, gstreamer, xine, openAL as long as it implements what LS needs to decode audio, then it could used.
However, a plugin should be listed as available if :
- it is present in the plugin directory
- it answers to the audio API defined for LS
And to be selectable only if :
- it detects that the backend is present on the system
Then, the user would have to choose between the different plugins which one should be used.
I don't know if this plugin idea could be extended to help the implementation of some other functionalities in the future...
But for sure it would be useful for the sound backend part. It could even be used under Windows or OSX where a plugin for DirectSound (or whatever it is called now under Win7) or Core Audio (which is an OpenAL implementation) could be used without having to code it in LS. For now, personally, I'll wait until work on the audio interface finishes, I know it is still changing a lot. But after that, I could make a fork and try to do something about it.
I'm not really a fan of multi backend plugin architectures. I'd prefer to have a single well working and fast backend. Actually pulseaudio is also supported on windows and so should be pretty ok. I will of course accept any contribution.