Of all the packages I maintain, the ones that have probably most users use are the ALSA packages, as if you need sound on Linux, ALSA is what you need.
Unfortunately, they are also the packages for which I receive most complains because they don’t do what some people want, or because upstream screw up and the configuration has to be changed manually every other release, or simply because you cannot use the in-kernel drivers with some alsa-lib versions and so on.
I took over ALSA from eradicator when he wasn’t taking care of it for a few months, and after that I had a lot of fiddling to do. There were problems with the init script for some systems, the support for PowerPC was totally broken, and a lot of bugs were reported.
After a few months I had to “fight” with fox2mike and the kernel team about the requirement of use alsa-driver to report bugs, as there were incompatibilities between in-kernel drivers of a version, and userland of another. Using in-kernel was easier, alsa-driver is a time waste, but many bugs I fixed by telling people to use the external version.
Every few weeks, I have a discussion about “why do we have alsa-driver in tree if ALSA drivers are in 2.6 kernel?”. And from time to time I get requests that I close as WONTFIX because they cover rare setups that, becoming more spread, would be an extra maintenance burden over me (because there’s no one else taking care of ALSA in Gentoo, mind you).
The current thing is about statically built-in ALSA drivers in kernel. Why are they bad? Well, first of all because it will take even more time to switch between them and alsa-driver (you have to rebuild the whole kernel), and there were problems in the past, of kernel OOPS, non-initialised cards and similar. But this is not enough yet, as there are problems with devices numbering, for who has more than one sound card, or uses USB audio devices. Even worse when using USB audio device, and you remove them on the fly, you might lose the device 0, that might fool some software up.
I don’t care if such a setup “works” for some users. They should not file bugs to me if they have problem until they move to a supported setup. I don’t want to start supporting such a setup because it’s too difficult to diagnose and has precedents of problems. I’m alone maintaining ALSA, and this is not good, considering that a lot of people relies on it working.
So, please try to use the suggested setup: alsa-driver, aligned to the same version of alsa-lib, no ALSA in-kernel, especially no built-in ALSA, and file bugs if you get problems, I’ll try to fix them as soon as I can, or I’ll tell you to file them upstream so that the developers will find the problem.
I’m afraid that USB and BlueTooth support right now is currently lacking a good script support, but the problem is that I don’t have compatible hardware to work on those 🙁
Anyway, the bottom line is, please understand if there are rough points, if not all the setups are supported, if sometimes a new release breaks your asound.conf and you need to reconfigure it, if you’re requested to change your setup when you report bugs. Manpower is the main issue, but it’s also almost impossible to cover all possible drivers in ALSA at the moment.
bad regression.alsa in tree is seeing much more exposion, use them.
Hey Diego, thanks for all the work.I actually have a Audigy 2 NX (USB) and I tell you it’s been working great for many ALSA revisions so far!Even all 7 channels and LED control works.The only ceveat is that if they are unplugged when in use, I have to restart the ALSA init script or none of my USB devices work. That’s not really a problem though.
I had no idea there were so many problems with the kernel alsa drivers. I’ll definitely think about that in the future the next time I have problems. It’s been a long time since I’ve used alsa-drivers.