On Thu, Mar 23, 2006 at 01:42:01AM +0000, carmen wrote: With the onboard sound device as 'card 0', it was easy to use that as a pcm output for all the oss applications other sound apps I want separate from my multitracking. Something that I won't break with my .asoundrc fiddling. I have another solution, which is use the dsp-map=1,2 argument to the snd-pcm-oss driver, to bring the ac97 consumer part of the envy24 card to the default position. 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. Regards, -- Joel Roth

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: 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