(If this is the wrong forum for this, my apologies; it doesn't seem to fit well in any of them, so I figured I'd try here because sound's what's not working.)

I've set up a server running Fedora Core 3. It was initially set up with a graphical environment (but only the most minimal one -- no GNOME/KDE), but after the first configuration, I removed rhgb/firstboot/xorg-x11 and whatever other packages to get a commandline-only box. (I also added a 'while true; do : done' loop in /etc/X11/prefdm to get rid of "x respawning too fast" messages.) I want the box to be a web/email server that can also play music for me through speakers attached to the computer.

If I use an attached keyboard/monitor, all these capabilities work perfectly as both root and as a regular user. The natural solution here (to me, at least) is to use ssh to log in from another computer to manage things. For the server stuff, ssh works fine. For the sound, however, it doesn't work.

If I log in remotely as root, the speakers will play sounds from mplayer (built from source for a gui-less environment). However, when I try to adjust the volume using 9 (down) or 0 (up), I get a message saying that hardware mixing is not available and that some type of filtering will be used. The volume level can still be changed ("filtered"), but the range is pretty severely limited, and I can't get the max volume I could get if I logged into it from connected hardware. If I log in as a normal user over ssh, sound doesn't even work. (Some other info: mplayer uses OSS to play sound; I tried compiling it with --disable-ossaudio, but then no sound worked, and I don't care enough ideologically to fool with something that works. FYI, aplay doesn't seem to work for me when I log into the computer, directly or remotely.)

I've found a partial solution to getting sound to work for the normal user, but it's only partial: create a group named 'sound-users', add the unprivileged user to it, along with root, and do "su -c 'chgrp sound-users /dev/dsp' -" to get sound to work. This doesn't fix the hardware mixing problem. Also, because FC3 is udev-based, this also has the problem of meaning that any time I turn off the speakers, I have to retweak the permissions for the speakers. I've looked at the permissions of /dev/dsp on a local login, and interestingly enough, when I log in as user foo, the owner of /dev/dsp is set to foo. This works for both root and the unprivileged login.

Because FC3 is udev-based, I've looked into just tweaking the udev config files to fix things. This doesn't actually work, though (or at least just tweaking 50-udev.permissions doesn't). /dev/dsp has the wrong permissions still, and I have a feeling that tweaking in 50-udev.rules to change the user associated with /dev/dsp won't really work, either (because that won't fix the hardware mixing problem).

Basically, I think my question boils down to this: how is an ssh login different from a local login, and what steps should I take to make ssh logins be functionally equivalent to local logins?

Finally, here's the output of some various bits of information from the affected computer. If more information is needed, just let me know.
Thanks in advance for any help!