On Fri, 2003-05-16 at 05:43, Dale Kosan wrote: > I upgraded three machines that have the Soundblaster Audigy sound card > and the following brand motherboards: Asus, Abit and Tyan. After > installing the new kernel sound quits working, I get a message about > device /dev/dsp does not exist and when I do a lsmod I see "initalizing" > next to the audigy entry. I remeve the modules for the Audigy and reload > them but I get the same efect. Any ideas? The kernel in question is the > one named 2.4.20-13.9. I used up2date the first time and manually > installed the kernel the second with the same results. I have since > reverted back to the older kernel and have no problems. Thanks in > advance for any input.... Sounds like a bug in the OSS modules. If you _must_ use the newer kernel, and you _must_ use the Audigy soundcard, and no one comes up with a simple workaround, perhaps you can try the ALSA drivers. >From what i've heard, Audigy 1 and 2 are supported by ALSA. You could compile and install ALSA from tarballs, but if you prefer a cleaner solution, take a look at the freshrpms packages: http://shrike.freshrpms.net/ I just noticed this morning that they've got updated ALSA packages for the most recent Red Hat kernel updates. I'll probably try them out this evening, once i download and install the kernel updates. You will need the following packages: - alsa-driver (the ALSA files in /dev and stuff like that) - kernel-module-alsa (the actual kernel modules, it's contained in the same link as alsa-driver, and pay attention to choose the version that matches your kernel exactly) - alsa-lib - alsa-utils (ALSA mixer, scripts, etc.) You will have to adjust your modules.conf to use the ALSA modules instead of OSS. I guess the best place to start with that is here: http://www.alsa-project.org/alsa-doc/doc-php/template.php3?company=Creative+Labs&card=Soundblaster+Audigy+Gamer&chip=Audigy&module=emu10k1 You will also have to comment out the existing references to the OSS sound modules. There are many things you can tweak afterwards to the module settings, just use the docs and the mailing list archives. If the /etc/init.d script contained in alsa-utils does not work for you (there are a few decisions that were made when creating that script that, to me at least, seem a bit awkward), then you may try out my version of it: http://florin.myip.org/stuff/alsactl My script requires S01alsactl symlinks in the 1-through-5 rc*.d runlevel directories, and K99alsactl symlinks in the 0 and 6 runlevel directories. The main ALSA native utility that you'll probably end up using is alsamixer, which runs in a regular xterm. Some controls in alsamixer have funky and non-intuitive names, hopefully you'll figure out what goes where. On many systems, using the regular OSS volume control application (gnome-volume-control or whatever is it called) works just fine, albeit at a less fine-grained level than alsamixer. After you adjust the mixer settings for the very first time (you _must_ unmute a few things that are muted by default), you may want to run, as root for this time, "alsactl store", to store the settings to /etc/asound.state. After doing that once, you can forget about alsactl, the /etc/init.d script will take care of everything. Reboot once you think ALSA is configured properly, to make sure everything comes up again as expected. After installing and configuring ALSA, your applications can continue to use their normal OSS output modules, since ALSA provides an OSS emulation layer that works very well. If you want to experiment, you can actually convert some applications to native ALSA output. On Freshrpms you'll find, for example, an XMMS-ALSA plugin (as RPM package) that extends that application's capabilities in that regard. Just poke around on that page, there are lots of interesting things out there. Some media apps on Freshrpms come with ALSA as a requirement, and they use ALSA by default, although usually there is a switch to fall back to OSS emulation, just in case. gxine/xine is one such example. Strictly from the perspective of the sound subsystem, ALSA is perhaps a technically better solution than the default OSS drivers. However, if you're not comfortable with using 3rd party kernel modules on your system, then maybe that's not the right solution for you. Personally, i use ALSA on every multimedia-enabled Linux desktop that i control. For me, overall it works better than OSS - i can put to serious work the Dolby 5.1 digital outputs of my soundcards, the latency of the sound subsystem is clearly better, the driver itself has more clever options and is more flexible. That being said, remember that, strictly speaking, it's still in beta. If ALSA works for you, i'd appreciate if you could send me some feedback - i'm looking to start using Audigy2 Platinum, and i want to learn as much as i can from other people's experiences with ALSA and the Audigy series, whether Platinum or not. Thank you. -- Florin Andrei "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato
