As you might already be aware of, one of my preferred methods to relax myself is to code something, and I mean in real programming languages and not bash. As I spent the day repeating builds of a MinGW32 compiler (that finally worked as intended!) and fixing wall sockets (if I find whoever implemented my house’s sockets, I’m going to beat the sh*t out of him), tonight it was time for some serious xine hacking, especially since this morning I spent half an hour trying to find why Amarok didn’t start, and the problem was the PulseAudio daemon was turned off (because in turn I forgot to re-emerge alsa-driver).
So I’ve started looking at the plugin to find what the cause of the deadlock was, and I seen that the way it was implemented was kinda strange: it created the mainloop manually, and then continued stepping through it.. not exactly the simplest way around it. So I decided working on it a bit, and I was able to get it to work using a threaded mainloop, without need for stepping through it. This code, currently in CVS, is already lighter than before, as both stepping and locking is done already by PulseAudio, and it works fine with xine-ui, but Amarok does not initialise the audio drivers. I’ve then started looking deeper and deeper into the plugin, and I’ve now redesigned most of it already.
While the current plugin creates the mainloop and the context when you open the plugin for output, which means it’s opened more than once while playing two streams at a time, I’ve changed it to actually do that part of the initialisation during the load of the plugin; it might make load time longer, but that should improve the responsiveness later on, I’ll see to benchmark it so that I can actually see if it’s good or not. When you open a new stream with it, it creates only the needed stream.
Instead of stepping through the mainloop, it’s using callbacks, like the ALSA plugin (that I remember working better than xine’s, if we get around the fact that it consumed the double of memory because of the multiple layer calls, xine > alsa> pulseaudio -> alsa), and that is where I’m stuck right now as I need to write a few more and hook them around.
When the new plugin will be ready, and I can see it’s beneficial to the performances, I’ll consider adding a new _pre version to Portage, as usual.
I do really hope to be able to improve the situation with PulseAudio, because I have at least one issue with it right now: when you start a stream it stutters for once, and then it plays fine, I hope to be able to get rid of that problem too.
Anyway, in the mean time, I really need some sleep… I had already some laugh, thanks to Chugworth; I suppose I’ll just complete some crosswords to get to sleep.
