This Time Self-Hosted
dark mode light mode Search

ALSA fun

Yes, my fun with ALSA never ends, even if they haven’t released a new version of their software yet (I should start using Voodoo dolls like Davide Bianchi I suppose – link in Italian only, sorry).

Today finally the reason why emu10k1 didn’t build with the unofficial snapshot of alsa-driver was found, so I gone for committing the fixed ebuild, and as a week passed since I requested comments about the ALSA_CARDS expansion, and nobody had any more concerns (Genone was okay with leaving the default to “build everything”), I’ve committed that too.

So from one side, now emu10k1 users can use alsa-driver without a problem, and on the other side, I had a mess to take care of as I’ve added about 133 useflags to alsa-driver, and I needed to describe them in a alsa_cards.desc file. Luckily I’ve been trying to learn the AWK language, so I ended up writing a simple (about 20 lines without comments) script that parses the (grepped) output of Kconfig files for ALSA from the kernel sources and creates an alsa_cards.desc file (or rather part of it).

Unfortunately when I decided to update the ALSA’s maintainer guide, I found that the .awk files are not allowed to be committed (and neither are .sh), so I’m now waiting for Infra to know if they can allow those two to be committed, as there would be quite a lot more sense if project pages can contain simple scripts used for maintaining the software.

The problem is that I haven’t been able to get the description of all the useflags for now, but I hope I’ll be able to soon.. and after that, I think I still have a few variables that are currently used by ALSA that we either don’t describe or don’t support and thus users don’t know… I think that USE_EXPAND variables being shown on the emerge -pv output is one of the best things we had in the past months.. thanks portage team!

Leave a Reply

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