so, many people have asked me why i quit working on audacious. well, the simple answer is: audacious is a pile of shit. this blog entry attempts to explain the reasons why audacious is a pile of shit.
before that, here’s a basic listing of reasons why i still use audacious anyway, even though it is a pile of shit:
- audacious is the only player which supports a simple enough plugin API where most people can write a plugin for it, and still get things right like multi-channel audio and floating-point audio representation
- gtkui is a damn-good UI that no other player with equivalent feature support has anything like it
- it already supports all the formats i want to play because i made/ported/whatever basically all the plugins to support those formats a long time ago (mpg123, console, psf, usf, etc.)
- it has pretty good transcoding ability via the filewriter plugin
- it has good dynamic range compression — necessary when listening to chiptunes
so, that’s the good. now, here’s the bad (and a lot of this has to do with audacious’s XMMS origin)…
absolutely no separation of concerns
Audacious, put simply, does not separate concerns into multiple processes. this is not shocking, as no other media player does this, but it does have the nasty side effect that many things become crashers. this is especially a problem when you consider that a lot of popular audacious plugins are third-party. trying to get sandboxing into audacious was like fighting an uphill battle; put simply, nobody was interested, even though the sandboxing technique has been proven in other applications like charybdis.
way too many threads
Audacious, due to lack of proper separation of concerns, uses threads in a way that is complex. a lot of the crashes in audacious recently were introduced when jlindgren added many more threads. plugins which simply were not stable enough due to assuming a simplified threading model got removed. to be fair, a lot of those plugins were shit and needed to go away anyway.
the plugin API is a disaster
because of the lack of separation of concerns, and complex thread model, the PAPI is now a disaster. put simply, you can’t be for sure what thread will call into your plugin at any time, so you must now have reader-writer locks to ensure you don’t get screwed over. if we had gone with the sandboxing model, none of this would have been needed. but we didn’t, and called it audacious 3.x anyway.
the goal and scope of my work in audacious-2.x was to reduce threads and move to a sandboxed, multi-process model. this would have been a big win for stability and security.
many plugins which had major improvements (*ahem* modplug) were changed back to using libmodplug library
you can blame fedora for this one.
audacious contained a rather non-trivial fork of libmodplug as part of it’s modplug plugin, which had many improvements to the impulse tracker loader, done by myself and Chainsaw (Tony Vroon). this was all destroyed when the current maintainers of audacious decided to go along with fedora’s demands that audacious just use the inferior libmodplug upstream library instead. so, if your impulse tracker modules sound wrong now, that’s why.
adplug is another example of this sort of stupidity (although that one can be easily fixed). if you’re wondering why you can’t stream adlib modules anymore, now you know why… because they ripped out the patched adplug sources, to appease fedora.
licensing of audacious itself is a giant mess
audacious simply needs a full license audit, right now it’s shipped under gpl3 because we are not certain if any XMMS originating code is still there. why?
so, there you have it. this is why audacious is shit, but i still use it anyway. maybe i’ll finish working on my sandboxing media player which solves these problems, someday…