[linux-audio-user] Using index=n option to assign Alsa drivers to card 0, card 1

Joel Roth res0u2uc at verizon.net
Thu Mar 23 02:56:58 EST 2006


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



More information about the Linux-audio-user mailing list