well guess wat i have solved my problem...i unplugged all the accesories and periphals and just had the speakers and essentials plugged in and the sound worked great. so i would suggest doing what i did and see if anything helps....good luck.

-Neo

well I would try that, but I got aggrivated and loaded suse back on my computer. I never had problems with sound or anything else working with suse, but I do prefer redhat since I am used to it, and like the feel of it. Next time I change back to redhat(I seem to change alot) I will try that then And I am glad to hear you got sound working. Cheers!!

thanks a lot...good luck to you to. =)

-Neo

I have the same exact problem with RH 8.0 and SB Live!. When I run sndconfig the thing just tells me that configuration is fine and the module is loaded, and once it plays the test sound it says that there is no such device as /dev/dsp. I am still a linux noob and i have no idea how to get this thing working. There is no option for Plug and play os in the bios. Anyone have any ideas on how to make this /dev/dsp thing work?

What BIOS?

I dug around and did find plug and play in my bios but it didnt help. I went ahead and started playing around with mandrake 9.1 after d/loading it off the net and everything works fine. I think I might stick around with that distro for a bit. but if you do get it to work, let me know. Also, I think I have an older sb live which might have something to do with it not working too well with sndconfig.

I have a gateway desktop
1.7 GHz Pentium 4
384 Ram
Sb Live!
Radeon 9000
I have no idea what bios I have.

dmesg | less
have to say about a driver called emu10k1??

no, not really. the only error message is that cryptic sound server startup failure at start of kde. when i run /usr/sbin/sndconfig it detects the module and everything but when i clik play test sound it just says error opening /dev/dsp - no such device.

So browse the /dev directory and look for dsp. If you find it, what are the permissions on it?

I allowed all users to read, write, and exec a couple of devices including /dev/audio, /dev/audio1, /dev/dsp, /dev/dsp1, /dev/mixer, /dev/mixer1, /dev/sndstat, and /dev/sequencer. i though i overdid it but, guess what. no more cryptic messages - just no sound at all. i tried to stick a cd in and everything and turn the volume all the way up, but nothing works. emu10k1 is detected and loaded, it just doesn't produce sound

I've found a few threads here and elsewere about problems with the SBLive, all of them end with silence, Did anyone fix their problem?

Anyone running RH9 with a SBLive? I tried ALSA, the creative drivers and anything else I could put my paws on. Giving up, next I guess I'll have to try recompiling the kernel.

I'll try to be good and post a solution if I ever get to one

honestly, i've come upon an interesting if baffling solution (kind of like standing near the tv to get better reception).

i'm using an aopen ax45-v board; p4. i have a sb live value in my second pci down, 2 slots away from anything else.

when i start my kde session it gives me a similar looking error as chuck, refers me to the file but if i poke around a little, it will start. i am thinking more that it takes a minute or so for the module to initiate than anything. almost like after repeated attempts it just gives up trying not to make sound and does it. if anyone has any experience with this let me know, or just reply.

maybe i'm just new to the whole scene and don't know what i'm talking about. i'd say that i'm getting it working but i know better and say i'm being as effective as a kid in the driver seat turning the key and fixing an engine problem.
thanks

Hello
I wanted to add to a few concepts already begun here about ways to get sound working. On the way there it is best if you can diagnose and checklist so you get an idea of your progress.
Before I go any further you should know that permissions on any devices you wish a user to have access to must be set. The best way is with chmod but since a lot of you here are so new and have migrated from windoze you'll be glad to know that you can also accomplish permissions changes by right-clicking on files in any filemanager and accessing the permissions tab. The devices of immediate importance are /dev/dsp. /dev/audio ( if your distro uses it ) , /dev/snd, /dev/mixer, /dev/midi, etc. While the list may vary due to distro or chosen driver ( Alsa uses it's own format but overlaps some ).
The next important step is to get into a terminal/console. I know this may seem foreign to a lot of doze refugees but here is the reason why: Any information you receive in a gui representation is just that, a representation, of a command and it's final results, minus all the important messages along the way. For example if you use Control Center and test a sound with the "Test Sound" button you either hear the sound or you do not. OTOH if you type "cat myfootest.wav > /dev/dsp " where 'myfootest.wav is some sound file youve copied to a directory that you can find and either change to or describe ( ie /home/user/myfootest.wav ) you will get the sound and/or you will get messages telling you valuable information such as "device does not exist" or "permission denied" just to name a few that obviously tell you what you need to do next. You can substitute "/dev/sound" or any other device you may think capable of playing that file to discover what works and what doesn't, what has proper permissions etc.
Additionally there are so many commands that help you discover what is loaded and if not why not such as "depmod", "modprobe", "insmod" and "lsmod". The last one lists all the modules that are loaded. The others attempt to install a specific module or switches can cause them to try all outstanding modules again, all of which will give you information feedback as to why it didn't load. If you try to accomplish all this in gui you are largely running blind.
Lastly, SBLive is supported at kernel level. You can recompile your kernel and set it to "yes" instead of "M" so that it loads support hard encoded right into the kernel. This almost always works when everything else kicks your butt. It really isn't hard to compile your own custom kernel and the value of doing so is long-lasting and very important to your sense of command and control over your environment and isn't that at least one of the reasons you got Linux in the first place? There are numerous documents that will walk you step by step through the process and you will learn how to create or modify a menu so you can choose from different kernels so you don't have to lose your working original, though you will want to once you see how much better one that is configured exactly for your particular box runs.
"Man", "info", "docs" and "HowTo's" are probably already in abundance on your computer already and if not they are just a google away. They can tell you what commands do and what switches are available and how to type them correctly. While some people may go overboard about the Command Line Interface, it is not without good reason since it puts far more power and information into your hands faster than any other way for *way* over 60% of jobs. Once you get you box "talking back to you" teling you what's going on, you won't have problems like getting sound working that lasts more than a few hours. Incidentally, while forums like this offer an important sevice because messages stay up for a long time, real time help is also useful and is available on countless IRC channels. As long as you are courteous and patient, most people won't be jerks. You meet a few but that's life and for every jerk you meet you meet at least ten friends. Good luck and see you guys around.