Summary: on my debian (predominantly) 'etch' system, the
assignment of sound cards to hardware device numbers (hw:0,
hw:1, etc.) can be controlled by the order of the
corresponding modules in /etc/modules. None of the
alsa-related alias or option entries in /etc/modules.conf
(via /etc/modutils/alsa-base) for this purpose, or for
influencing OSS pcm assignments had any effect!
Following the advice of carmen in this thread, I undertook
some systematic investigations.
Perhaps I should retitle this thread, "Black-box tests of
Alsa module configuration," since that is practically what I
am doing here: trying out stuff from the Alsa docs, seeing
what options work for me, finding a surprising number that
*should* work but appear to do nothing on my system.
On Thu, Mar 23, 2006 at 02:30:38AM +0000, carmen wrote:
> > However, I would hope to make sense of the various parameters
> > 'index=0' 'snd-card-x' 'snd-slot-x' to better cope with
> > future hardware changes. And software changes, too. Some
> > configuration change (maybe installing udev) caused the card 0/1
> > assignments to swap, so I'd like them to static if possible.
>
> ## alias snd-card-0 snd-interwave
> ## alias snd-card-1 snd-ens1371
> ## OSS/Free portion
> ## alias sound-slot-0 snd-card-0
> ## alias sound-slot-1 snd-card-1
>
> so, you can have /dev/dsp1 be hw:0 and vice versa...
Here are my interim test results, which, pending feedback
from the list, I will post to the wiki.
I am using a 2.6.15 kernel (compiled by myself), using udev
to populate the /dev directory. I have two sound cards,
corresponding to the snd-ice1712 and snd-via82xx drivers.
The drivers are compiled as modules, and are loaded
automagically. My system is Debian-based, most packages
from the 'etch' (testing) distribution, with a few from
'sid' (unstable). To use udev to generate device nodes and
replace hotplug required installation of the binary package:
apt-get install udev
In this configuration, drivers listed in /etc/modules are
loaded in one step during boot ("Loading Modules"), then
further drivers are loaded in a second step, ("Discovering
Hardware"). Initially the sound drivers were not listed
in /etc/modules.
Mapping from physical soundcards to hw:0, hw:1
==============================================
The assignments from the VIA card to hw:0 and the ICE1712
card to hw:1 reversed during an upgrade. I attempted to
make a static assignment.
The assignments were inspected by the following commands:
$ cat /proc/asound/cards
$ cat /proc/asound/modules
The multiple soundcards page of the Alsa wiki
(http://alsa.opensrc.org/MultipleCards) and other references
suggest several methods to accomplish this:
1. Passing arguments to the drivers
A) As optional arguments in /etc/modules.conf
In my case /etc/modules.conf is generated from
alsa-base and other files in /etc/modutils by running
(sudo) update-modules from the command line.
I made the following additions to /etc/modutils/alsa-base,
options snd-via82xx index=0
options snd-ice1712 index=1
run update-modules, and rebooted.
Result: no impact on assignments
B) As boot arguments for a kernel with statically compiled
drivers. For example, a grub kernel declaration might look
like this:
kernel /boot/vmlinuz-2.6.15.6 snd-via82xx.index=0 snd-ice1712.index=1
Result: untested
2. By use of aliases in /etc/modules.conf (in my case, by
modifying /etc/modutils/alsa-base)
--
alias snd-card-0 snd-via82xx
alias snd-card-1 snd-ice1712
--
Then update-modules and reboot.
Result: no impact on assignments
3. Controlling the order of module loading by entering the
following module names in /etc/modules, then update-modules
and reboot.
-----
snd-via82xx
snd-ice1712
-----
Result: Success! Soundcards assigned to hw:0, hw:1 in order
of driver appearance in /etc/modules.
Changing the default mapping of soundcards to OSS pcm devices
===============================================================
Usually the first pcm of the sound card (hw:0,0) maps to
/dev/dsp and the first pcm of the second sound card (hw:1,0)
to /dev/dsp1.
I wondered how I could map the first pcm on the *second*
card to /dev/dsp.
This seemed easier, as I had only one approach to try,
changing an alias entry in /etc/modutils/alsa-base followed
by update-modules and reboot.
----
alias sound-slot-0 snd-card-1
alias sound-slot-1 snd-card-0
----
As I understand it, sound-slot-0 is the symbol
that Alsa assigns to the OSS device /dev/dsp,
and sound-slot-1 is the symbol Alsa assigns to
/dev/dsp1. The first line says that the second
sound card should be aliased to the first OSS
pcm.
Result: no change in soundcard-to-/dev/dspX mapping whether
tested by playing a wave file
$ bplay -d /dev/dsp test.wav
or by checking /proc/asound/oss/sndstat
$ cat /proc/asound/oss/sndstat
Discussion: I begin to see a pattern. NONE of the changes
I made to /etc/modutils/alsa-base and propagated to
/etc/modules.conf influenced my Alsa device driver
configuration. This merits further inquiry.
Selecting from among several pcm devices for mapping to OSS
===========================================================
This is covered in detail in
http://alsa-project.org/~iwai/OSS-Emulation.html
although maybe not clear on the first reading. I will give
an example. First let's look at my choice of pcm devices.
$ cat /proc/asound/pcm
00-00: VIA 8237 : VIA 8237 : playback 4 : capture 1
00-01: VIA 8237 : VIA 8237 : playback 1 : capture 1
01-00: ICE1712 multi : ICE1712 multi : playback 1 : capture 1
01-01: ICE1712 consumer : ICE1712 consumer : playback 1 : capture 1
01-02: ICE1712 consumer (DS) : ICE1712 consumer (DS) : playback 6
In short, under Alsa/OSS emulation, I can map one pcm from
card 0 (VIA) to /dev/dsp, and one pcm from card 1 (ICE1712)
to /dev/dsp1.
(I can also map one pcm from card 0 to /dev/adsp, and one
pcm from card 1 to /dev/adsp1, a believe the second pcm on
each card by default.)
To select a different pcm for mapping to /dev/dsp or
/dev/dsp1, I supply an argument to the snd-pcm-oss driver.
$ modprobe snd-pcm-oss dsp-map=m,n,o,...
where
m: pcm selection for card 0
n: pcm selection for card 1
o: pcm selection for card 2
For testing, I used the following command line:
$ sudo modprobe -r snd-pcm-oss; sudo modprobe snd-pcm-oss \
dsp-map=0,1; cat /proc/asound/oss/sndstat
In words, remove the driver, insert the driver using pcm 0
for card 0 (VIA), which according to the above listing, has
a four-something surround mode; use pcm 1 for card 1
(ICE1712) which has a single (stereo, certainly) playback
pcm.
Discussion: Whether supplying an 'options' entry for the
snd-pcm-oss driver in /etc/modutils/alsa-base will actually
work the same way for me as the examples here using modprobe
is an exercise I will leave for tomorrow. I invite any
predictions on the outcome, following changes to the file,
update-modules, confirmation by checking /etc/modules.conf
and rebooting before cat'ing /proc/asound/oss/sndstat.
Configuration errors could arise in these tests by typing in
'sound' for 'snd' in identifiers or vice-versa. I carefully
followed the documentation and viewed adjacent entries (when
in Rome...) so that some other explanation for why all the
option and alias settings I attempted had no effect is still
wanting.
Perhaps I made some error in my kernel configuration. I will
test a stock debian kernel tomorrow.
--
Joel Roth
