Over the last few days, I have been working on merging audacious-1.5 and bmpx, to create an XMMS-lookalike GStreamer player.

It’s fairly “stable” now, some stuff is obviously not there yet (Tuplez for one, getting stuff like bitrate etc for another), but you can check out the Hg repository at http://hg.atheme.org/users/nenolod/mudkip-player.

What does this mean for Audacious and BMPx?

Absolutely nothing will change involving both projects. The goal here is to create a simple player which looks like XMMS to satisfy the demand created by XMMS removal in many distros. Both already existing projects have their own direction, this is just a shared goal to create a solution for the strain placed on our projects.

Hopefully distros will take this as a hint and run with it. Hopefully.

Tried to switch a CentOS domU from the Debian kernel to pyGrub + CentOS kernel today. Here’s what I discovered:

• the redhat initrd sucks
• unsurprisingly, the debian initrd will not work with a redhat kernel
• modifying the redhat initrd to do the right thing is impossible
• lets try using hdaX: no. that didn’t work.
• apparently using e2label to force a filesystem label helps? nope.
• nash is not really a shell, but instead an evaluator of static commands
• mkinitrd is a horribly written bash script
• modifying mkinitrd to generate /dev/hdaX and /dev/sdaX? no dice.
• trying to embed a shell into the initrd like in debian’s initrd for debugging? impossible.

I gave up for the night. Sadly that user is probably going to post a horrible review of my Xen hosting service to WHT now. Oh well, it’s not as if I needed his $5/mo anyway. Yes, $5/mo apparently gets you the privilege of 24×7 support now. I didn’t know. Update: Oh, cool, apparently he didn’t.

Update: According to the CentOS wiki page on the subject, providing a virtual disk instead of a LVM volume makes it happy. The problem then is that any VMs made using an LVM partition can’t be transferred to a virtual disk, as the whole LVM volume is a filesystem. Or am I missing something? I suspect RedHat calls this a feature, personally I call it a bug.

Recently, we’ve been getting a lot of the following on our IRC channel:

<intangir> well xmms could do it

<intangir> and now xmms is no longer being updated

<intangir> its just been taking out of new debian and ubuntu repos ;(

<intangir> so audacious is the only thing that is close

<intangir> it must fill the void!

This is incorrect for a number of reasons, I am sorry if your distribution or the internet has made you believe that we are some magical successor to XMMS. This is not the case. Furthermore, calling us a “disgrace to open source” because we have no interest in being like XMMS (even the winamp2 skins are due to be leaving at some point), does not make us want to help you.

Now, why do people think Audacious is not acceptable replacement to XMMS? Well, not all people do, it’s more of the 5% of people who have specific use cases not covered in Audacious. Clearly if Audacious was not suitable, a lot of people would be blogging about it. Instead, we only see a few people blogging about it.

However, that said, I think Audacious’s focus is probably not the right focus for an “XMMS replacement” solution, and I have a plan for that (although once I finish writing it, someone else will likely be maintaining it, as I don’t really care enough). More on that later.

ss=”entry”>

Ubuntu’s audio team has patched my code using a “new approach” to make audacious use Pulse by default! Great right

Well, not really, because the way they do it is wrong and won’t work and is prone to breakage with future releases.

Here’s the patch:

@DPATCH@
diff -urNad audacious-1.5.0~/src/audacious/main.c audacious-1.5.0/src/audacious/main.c
--- audacious-1.5.0~/src/audacious/main.c       2008-03-13 17:19:27.000000000 -0500
+++ audacious-1.5.0/src/audacious/main.c        2008-03-14 12:38:13.000000000 -0500
@@ -174,7 +174,7 @@
{0.0, 0.0, 0.0, 0.0, 0.0,             /* equalizer bands */
0.0, 0.0, 0.0, 0.0, 0.0},
1.2,                        /* GUI scale factor, hardcoded for testing purposes --majeru */
"/usr/share/audacious/Skins/Classic1.3",                       /* skin */
-    NULL,                       /* output plugin */
+    "/usr/lib/audacious/Output/pulse_audio.so (#0)",                       /* output plugin */
NULL,                       /* file selector path */
NULL,                       /* playlist path */

As you can see, this patch is wrong. Why? Because:

• It uses an absolute path, and an absolute plugin UUID.
• The value will probably be ignored on first run for most people anyway, resulting in it using ALSA.
• Obviously we can’t support this change upstream, where all of the Ubuntu users come to ask everything anyway.

I like that, as usual, upstream was not consulted or asked in any way about how to go about making it do what they want. While my first try was wrong, it’s actually wrong due to a bug in audacious; that is the way they should patch it, and they should switch back to my patch in 1.5.1, as the weighted plugin detection is fixed there*.

*On my branch only. Which i will be pushing to proposed/audacious-1.5 soon enough.

Update: apparently some people took this the wrong way and assumed I was flaming Ubuntu here. Why would I? No, I was ranting about the fact that this guy changed a bug and within minutes uploaded this hideous patch. There wasn’t even realistically time to reply to the bug, nor was the patch posted for any sort of public review before hand. Anyone familiar with audacious’s internals would have immediately recognized that the patch is bogus.