Good Evening to all,
I don't know what udev does when it first loads during boot. My sound is found fine, the modules are loaded fine, and playing sound through xmms, Mplayer, and Xine is fine(looking at the properties, it looks like they all go directly to the hardware...but back to my problem). I went to play Kohan: Immortal Sovereigns, and it plays, but without sound. Checking the readme, I found out that it looks for /dev/dsp to play sound, which is nonexistent on my machine. The closest I came while googling for an answer(2 days so far) is this:

Not enough posts to post the url

Somehow udev creates my /dev/sound directory as a device, and I did what he did, reinitializing the udevd, and just like him it created my /dev/sound/* nodes and the symlinks to /dev/dsp, but it broke my /proc permissions. If I do it while running a window manager(Gnome, fluxbox so far) I can get the game running with sound, but I'm unable to use any console apps any more. So I have to reboot before I'm able to use my programs again( I am slowly learning to love console apps..)

By the way, trying to cat a file to /dev/sound does not work.

Oh and one more thing, I'm running Slackware 10.0 with kernel 2.6.10 and my audio card is a SoundBlaster Audigy 2

well..ther was a thread about that just a week ago or so...
when you run " #/etc/rc.d/rc.udev " , ( after you booted ) ,the devices will appear.

but it's not as it should be ? ( and that's a Q )

egag

I'm sorry I forgot to write that in my post. Yes, when I do /etc/rc.d/rc.udev it creates /dev/sound as a directory with all the nodes in it, but my /proc permissions don't work any longer afterwards. Trying to access a console app or virtual terminal spits back an error saying something along the lines of:

rxvt: can't open pseudo-tty
rxvt: can't open

And it's the same for any other console apps I try until I reboot, turning /dev/sound into a node again.
From what I remember of it, the /proc permissions can't be re-initialized without a reboot. So in closing, no, doing /etc/rc.d/rc.udev at a command prompt fixes my problem, but causes others.

Actually, it's /dev/pts that gets screwed (if you dealing with the same issue I posted about). That's why you can't spawn a console. Just remount it after you run the udev script.

I think I may have found the solution to the overall issue. I am testing it right now. I have two systems that are identical, but one has the sound bug with udev and the other does not. Same distro, same kernel version, etc. The difference is the one without the bug has soundcore compiled into the kernel, and NOT as a module. Soundcore is the flaw. According to udev's rules, when it encounters the soundcore module, it creates /dev/sound, and then all of the OSS devices pile up on it. I am recompiling and I will post the outcome.

--Akshun J

My fix works! Recompiled 2.6.10, and compiled soundcore (Basically, the option that says your computer is capable of making sounds, NOT the ALSA or OSS options) directly into the kernel. On next boot, all the alsa-oss sound devices (/dev/dsp, etc) got created correctly. Hope this helps someone!

--Akshun J

Yes, that was the fix i needed for this. I thank you akshunj and egag for helping to solve it.