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.
