DO NOT run your Linux system as root. The Slackware-HOWTO told you to create a normal user account:
So if you haven't created a normal user account, do so now

One step at a time, Kyle.

Next...

Don't mute your master volume if you want sound. :}

This has probably been said before:
After you've created a normal user account, login as that user - not root.
Then run "alsamixer" as that normal user, and don't let any of your volume levels
get red at the top. And leave the mic ones muted. Once that's done, hit ESC to
exit alsamixer.

Type "su" to login as root and run "alsactl store" and then exit to logout as root
and become the normal user again.

As we say in China - "man man lai" ~ little by little...

I think thats it!! I'll try it.

I would just like to state that I have been having the same ear splitting issues with Slack 10, alsa, KDE, and SB live. I was reminded of the Star Trek episode when some alien was abusing the crew with high frequency sound - I was doing a total Captain Kirk thing while I tried to find the applet to turn down the volume.

I did notice a couple things -

Running aumix showed settings for a chipset I did not recognize as well as the SB live- I think the wrong driver or multiple drivers may have been loaded by alsa - the sound is like feed back.

Changing any of the settings in aumix regarding the channel that is being recorded from made the sound go away. This was not a permanent fix.

Commenting out the OSS lines that alsa adds to modules.conf made the problem go away as a user, but not as root.

The above action allowed sound without screeching, but caused complaining by kmix, volume control, and aumix that they could not find a mixer.

Uncommenting the lines in modules config fixed nothing and now, when I log in to kde I no longer have permissions to /dev/dsp when I did before - hmmm....

The problem is only present in KDE. Gnome never screeched.

I just wanted to share. Still searching for a solution.

By the way, Slackware 9.1 had no such issues - even when upgraded to current/10
This has just been in a clean 10 install.

This has nothing to do with ALSA, but might be related. Whenever I exit KDE (and thus X), my keyboard repeat rate goes way down, and I can barely type. It's fixed by using kbdrate (as root), but it's annoying as hell. I have a feelign there is something seriously messed up with KDE.

I just wanted to post that I fixed the screeching sound problem.

I uninstalled alsa and associated packages, deleted alsa edits to modules.conf, made sure the emu10k1 line was commented out in rc.modules, rebooted to run level 3, ran lsmod to make sure no sound modules were loaded, re-installed alsa packages, ran alsaconf, ran alsamixer, ran alsactl store, started x, booted to kde as root - went to control panel and set sound to alsa etc and tested - all good, left kde and logged back in as user, konsole, su, chmod 777 /dev/dsp, control center, set sound to alsa etc, test - all good.

HTH

also, I did want to mention that I didn't notice the sound screeching till after installing the nvidia drivers - but this was very soon into the whole process so the problem may have been there allready, I just don't know.

Thank u!

what are the correct permission so a user can also use sound. Is chmod 777 /dev/dsp enough??

I've been running Slack 9.1 since November, and have done several installs on
both my comp, and at least a dozen others. I have never needed to use
this permissions philosophy for users. Everytime, no matter what mobo or pci
card, I go to ALSA, get their latest drivers, look up the soundcard, and copy
and paste their instructions. After I insert the modules, I log out as root and
as a normal user I issue "alsamixer" and use the m key to unmute the volume
levels, turning them all up until about 72 (if there are color bars I stop before
they turn red). Then I su to root and issue "alsactl store" and this saves the
settings permanently.

This has always worked for me. I've seen people posting this chmod for
/dev/dsp but have never found the need to do that. Looking at two comps right
now, this is what I see from a standard install of Slack 10.0
and Slack 9.1
and sound works great for both of them. Yes, as a normal user. I don't login
to a *nix system as root. That is rather "er bai wu" :}

now that isn't very nice...

It wasn't meant to be ugly - just speaking "the truth in love." :}

oh, i know what you were going for. logging in as root on a *nix system IS a bit worse than generally stupid, in my humble opinion that is. i know plenty of guys who do it all the time. i've called them worse, trust me.

Hey, mate - apparently you can read Pinyin. Weishenme?

After running Windoze for a couple decades, and finally finding Linux to be
friendly enough to desire to migrate, there are a few things that someone
should really appreciate about Linux. One of the greatest to me is this area
of security. If one properly sets up a *nix system, with a normal user(s) as
well as root, and logs in as a normal user (except for commands that only
su can issue) for day-to-day work, the system is far more secure than any
Windoze OS ever shipped. And just that one thing makes it more secure
than the latest - Windoze eXperiment - by far.

But, eh, it's a PC (Personal Computer), right? So one's free to use
it, break it, or whatever one wants.

To give a shining example of that...

Yesterday I put a third hd in this box - /dev/hda has Windoze and my Linux swap,
/dev/hdb is the CD-RW, /dev/hdc was my Slack-9.1 system, and /dev/hdd
is now Slack-10.0. My intention was to pull /dev/hdc soon and use it to build a
server.

So as I'm doing other things, the Slack-10.0 install happened as I ran in and out of
the office. Coming back I decided to run through it until it started installing packages
whilst I took a quick nap. However, when it came to the TARGET option I wasn't
thinking that when it scanned for Linux partitions, it would pick up /dev/hdc as well as
/dev/hdd - and off I went formatting /dev/hdc1-6 before I noticed the c instead
of d and had formatted all but the /tmp partition.

NB: Backup - period. I last did it on 2004/05/22 so I do have a considerable amount
of that data left. However, there are some things that I won't be able to replace. I'm
still counting on some of these smart Chinese fellers being able to work a miracle and
recover that drive.

And I guess one doesn't have to be "er bai wu" to run their shiny new Linux system as
su on a daily basis ~ but it sure seems that way IMO.

Chinaman mumbles as he tries to get the M$ IntelliMouse Exploder to work again...

i had a chinese roommate in college. i can't read much, but i picked up some here and there. seeing "er bai wu" in your post was pretty nostalgic, as this was what he most often affectionately called his mother. that's what i do best.

regards

I have noticed that once I add more than one user to the system, one user seems to have ownership of the /dev/dsp symlink and the others complain about permissions untill I chmod it.. I'll admit I'm not in complete understanding of why I need permission to use the sound in the first place. I'll also admit that some things are (to me anyway) not important enough to fully explore once you have found a fix that seems to work.

I think perhaps I got into the habit because I have seemed to have issues with getting alsa to work in the past and, as such, have been (stuck) with OSS. Not having the alsaconf capability in this situation, the chmod approach was the best for me and it became habit.

Oh well, back to work

Here's question for someone;

Why is it that when I (as user, not root) log into KDE from kdm (started as root from runlevel3) do I get this error:

Sound server informational message:
Error while initializing the sound driver:
device: default can't be opened for playback (Permission denied)
The sound server will continue, using the null output device.

But when I log into KDE from gdm (started the same way) I get proper sound setup.

Hmmm.

These are my device permissions:

lrwxrwxrwx 1 root root 4 2004-07-02 15:39 dsp -> dsp0
crw------- 1 root root 14, 3 2003-08-29 03:47 dsp0


I know gdm allows a sound event when it starts, this must have something to do with it.