This Time Self-Hosted
dark mode light mode Search

New chapter in the ALSA mess

So, there we are, Linus released kernel version 2.6.20, and alsa-driver-1.0.14_rc2 does not work; I had to create a new snapshot, and to get into the tree.

The problem is that this time the snapshot is after rc2 and before, well, I’m not sure if rc3 or final release, so I couldn’t just use _pre or _p; I ended up setting the version as 1.0.14_rc2_p3234, but this required me to ping and prod Zac because I wasn’t sure which versions of Portage supported this format, and because repoman decided not to allow me to commit this version. Thanks to him and Brian, now this is fixed.

Now ALSA should be all fine and ready for people to upgrade the kernel, without having to use the mercurial versions. Today was a day off, tomorrow it will be a work day, I’ll probably just be going to sleep soon, but I admit that listening to Dream Theater was quite relaxing today; too bad I can’t really work with DTs in the background, I’d need some Jazz music for that, it has proved to be quite good while designing and coding.

Anyway, for tonight I did my share of stuff.

Comments 6
  1. I always appreciate your work on making ALSA tick, and indeed, gotta love Dream Theater. Ever listen to Shadow Gallery? Good stuff.

  2. Seeing how often you have to bump alsa-drivers for kernel forward compatibility issues makes me wonder: in general, does this new versions preserve backward compatibility? For instance, is it safe to upgrade to 1.0.14_rc2_p3234 on my 2.6.19 kernel?I don’t know if you find time to test alsa-drivers this way, but if you do, i would actualy much appreciate some pkg_setup warning when i’m out of your tests range. Something like:if kernel_is -gt 2 6 20 ; then ewarn “Your kernel ($KV_FULL) is more recent that the latest release this drivers were tested on (2.6.20).”elif kernel_is -lt 2 6 18 ; then ewarn “Your kernel ($KV_FULL) is older that the oldest release this drivers were tested on (2.6.18).”fi

  3. Thank you for providing us always the latest bleeding edge releases, but also keeping the stable releases working proper as the should!I think you’re one of the devs that make using Gentoo a pure joy.Thank you!

  4. First of all thanks to all of you :)Andrew: no actually I don’t know Shadow Gallery, but I’ll be sure to check it out!TGL, the forward-compatibility of ALSA is just supposed, and if it’s not compatible it is easy to see: it fails to build 🙂 That’s why I always follow the stable kernel with a stable ALSA, to make sure the deptree is always fine. The backward compatibility is usually handled by ALSA devs, and quite decently: they patch their drivers to work with older kernels, and this is usually fine. I tested 1.0.14_rc2_p3234 on 2.6.19 (this is what I’m running, too) and it’s fine. Luckily, it also works with the current version of alsa-lib.I don’t think I would have time and motivation to actually start testing all the previous kernels to see if it works though, I leave that up to the arch teams if they want, because really, I’m not paid to do ALSA work, and it is enough of a trouble as it is now.

  5. nice work on the alsa driver but my cron job on the server always send me an E-mail about:Garbage at end of version sting: _p3234Perhaps you can do something to tell eix it is okay or remove the version from the repository after the new version is on the server.

  6. Mark, the problem is that eix does not implement the whole version regexp that instead Portage (and the other PMs too, as far as I know) support.. sure I’ll be removing that snapshot as soon as there’s an alsa-driver release that actually work, but eix has to be fixed, and I can’t do anything about that.But as everybody is seeing that right now, it’s likely that it will be fixed soon.

Leave a Reply to FlameeyesCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.