Craziness and ALSA (unrelated, maybe)

Okay, let’s start with a catch up related to yesterday’s blog. I’ve committed Pacho’s fix for kdelibs, kdebase and kdebase-startkde, GNOME users should have their old menu again now after update; I also committed the fix for latest libtorrent, that was failing to compile on ~amd64, and added TorK 0.13, with a warning if you built tsocks without the tordns useflag, under package.mask and depending on the new series of tor.

A bit of a commentary about that: TorK 0.13.1 was released earlier today, supporting the current stable series of tor, and thus would be able to be used with the unmasked tor, but I talked with the author (Robert Hogan) and he prefers to leave 0.12 unmasked and get 0.13 with full features of the current alpha tor.

Another change that is going to take by surprise a lot of users today is that amarok, both 1.4.4-r4 release and 9999-r1 (this is to force people to rebuild), now depends on www-servers/mongrel. The reason for this is that up to today, Amarok was shipping, building and installing its own copy of mongrel, of rubygems, and gem_plugin, which is bad security practise and again policy; by this change you won’t have much more stuff installed in your system, it’s just that it will be installed by other ebuilds. And no, Ruby cannot be removed as a dependency (it is used by core functions like ratings and lyrics, and last.fm support) and upstream does not like to get features like DAAP sharing disabled, so it will stay.

Now, let’s go a bit into the craziness part before some important things about ALSA. Who’s craziness, to start with? Mine of course. Let’s try to clear this up: since my mother started using her iBook, she’s printing tons of stuff she finds interesting on the ‘net, the main cost being, for me, the paper, as I have a laser printer that is quite cheap when it comes to toner, especially now that I started buying it at K&M. Unfortunately although the printer (a Kyocera FS-1020D) is quite fast when it comes to print text (sources, manuals), it’s quite slow when she prints pages with images and graphical content, probably because of the limited on-board memory (just 16MB). I’ve been looking around for which kind of memory expansion I should use, as the manual described it as DIMM, but it wasn’t the usual 168-pin DIMM bank you find on older PCs.. a quick search around found the official part number being MD-256 for the 256MB memory expansion, present in Kyocera UK catalog for £319 yiekes!

Fortunately, third party memory seems to be quite cheaper, and thanks to Lisa, I was able to find an expansion on Crucial’s site, not the 256MB model, but 128MB is still better than nothing, especially since the price wasn’t bad (€36). Up to now, no craziness, it’s a perfectly sane upgrade operation. But then the crazy idea, let’s see how much the memory for enterprise costs.. uh, €168 for a 2GB pair.. and my processor would support dual channel, if I didn’t buy just one RAM module. So at the end, I spent a lot of money and ordered the 2GB pair to see if this will improve the performances of the box. It would be nice to be able to cut down the merge time for KDE-related stuff, as it’s often quite high, like today I had to wait for kdelibs to complete before moving on to libtorrent, and then wait for that before moving on to Amarok and so on… so I suppose I can say I bought this memory just for Gentoo 🙂

And now a different kind of crazy stuff, ALSA. Seems like 2.6.20 is going to be even worse than 2.6.19 and its predecessors, as upstream broke quite a bit of things. First of all, right now neither release nor live Mercurial versions of alsa-driver work with the 6th RC. How could they break it so much, I have no clue about.

But also, this new version breaks HAL, as they changed the sysfs placement of the information, so the current version of HAL will not show audio devices with 2.6.20 kernel, unless you get the old sysfs support (now deprecated during 2.6.20 release candidates… no comment), and a specific patch is applied to fix their own breakage of the sysfs structure. For more information, please see PulseAudio Ticket 51 for more information. Sigh.

Okay, this is a preview of the mess I’ll end up taking care of as soon as 2.6.20 is released. What about the current status of ALSA though? I have updates for that too. If you haven’t noticed, udev now loads ALSA’s modules before alsasound is started, so alsasound is really just a mean to restore the mixer levels. I’m now pondering if I should just replace the init script with a version thart doe snot change hte modules status and simply loads the mixer levels, and get it to start when udev starts the sound modules, kinda like the bluetooth service. I’ll have to talk with Roy about this as I have no clue how that works though, and I also want to still provide a decent way to reload modules so that you don’t have to do it manually when you update ALSA.

Another thing that has to be taken care of is that, as far as I can tell, udev ignores the snd-card-${index} setting, so if you want to make one particular module start the Nth card you need to use instead index=${index} as an option. For instance to map an emu10k1 as first card, and a via82xx as second, use this:

options snd-emu10k1 index=0
options snd-via82xx index=1

inside /etc/modules.d/alsa.

I don’t think either the guide or alsaconf do that right now, the first is to be updated, the latter I’d rather remove, if it was for me.

So this is the current status of ALSA, and a few notes on the changes done today, with some news from my own world… but of course it’s not ending here, as the ALSA issues will be addressed, somehow.