I managed to solve my own problem with my previous issues with ALSA on devfs.
I'm going to share them in case people have the same issues. (and they will on
devfs)
In /etc/init.d/alsasound (the alsa startup/shutdown script) there is a small
section that allows a user to have a little script run on startup to take care
of any issues that would always need to be done for whatever reason.
The snippet of code is
# run card-dependent scripts
for i in $drivers; do
t=`echo $i | sed -e 's/snd-card-\(.*\)/\1/'`
if [ -x $alsascrdir/$t ]; then
$alsascrdir/$t
fi
done
$drivers in the script represents the snd-card-* lines in /etc/modules.conf
in my case it comes back with "snd-card-emu10k1"
$t from above is then equivalent to "emu10k1"
What it does is look for a file in /etc/alsa.d that is executable that is the
name of the DRIVER used for your card. So on my box I use a SoundBlaster live.
The module is snd-card-emu10k1. This script is looking for a file called
"emu10k1". If it finds it it will run it when the alsasound script is called
with the "start" argument. (redhat/mdk sysVinit style systems.) Others may use
a different script, check your systems.
In that file I put in three simple lines:
modprobe snd-pcm-oss
modprobe snd-mixer-oss
modprobe snd-seq-oss
make sure the file (emu10k1 in my case) is executable (chmod +x emu10k1) and
its located in the /etc/alsa.d/ or in the place defined by the alsascrdir
variable in the alsasound script. My script defines it as:
alsascrdir=/etc/alsa.d
This takes care of getting OSS compat loaded every time alsa starts.
If you are NOT using devfs, then you can just reset the permissions of the
audio devices by hand with chmod/chown. (or use the ./snddevices script in the
alsa-driver source to do it for you)
Now permissions of OSS modules on devfs systems, is taken care of in
/etc/devfsd.conf
There's two ways to do it, one is the Mandrake (and probably other vendors
ways)
# Vendor way
REGISTER sound/.* EXECUTE /sbin/pam_console_apply
This requires reading the man page for pam_console_apply ahnd making the
necessary adjustments to the files referenced in the man page.
Or the simpler (yet potentially less secure way)
REGISTER sound/.* PERMISSIONS root.audio 660
USER.GROUP MODE (rw,rw,no-access)
Make sure the user account that you run OSS audio apps is either root, or in
the audio group. (you could use any group name if you want)
I've found the second way easier to use and simpler for my usage situation, you
may have reasons to NOT do it this way.
The last is ALSA permissions. These are controlled from modules.conf as
paramaters to the snd module as below. The only thing I don't like is you have
to specify the uid/gid as NUMERIC, not string based. (Thus I have to use 81
instead of "audio") Notes to developers: Is it too hard to make it accept the
string equivalent, since I doubt gid 81 is the audio group on all the various
linux distributions.
options snd snd_major=116 \
snd_cards_limit=1 \
snd_device_mode=0660 \
snd_device_gid=81 \
snd_device_uid=0
This makes all the /proc/asound/dev nodes owned by root.audio (audio is gid 81
on my box) at mode 660 (rw,rw,no access)
Hopefully this info will help new and seasoned users...
=====
Dave J. Andruczyk
Enterprise Resource Providers
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
