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 RothReceived on Thu Mar 23 12:15:01 2006
This archive was generated by hypermail 2.1.8 : Thu Mar 23 2006 - 12:15:02 EET