At 16 Dec 2002 19:46:55 -0800, Mark Knecht wrote: > > On Mon, 2002-12-16 at 18:51, Paul Davis wrote: > > > > > i think it would something like this: > > > > options snd-hdsp snd_index=0 > > options snd-usb-foo snd_index=1 > > > > i'm sure that takashi or jaroslav will correct me if i got this wrong. > > > > --p > > Paul, > This makes perfect sense, and it isn't what I did. (!!) > > The PlanetCCRMA has a Nano-HOWTO on how to install the MidiMan 2X2 by > hand. It's a little USB-based MIDI interface (not a sound card) that is > not recognized by alsaconf, so we do a bit of editing by hand. > > alsaconf sets up modules.conf for the HDSP > > # --- BEGIN: Generated by ALSACONF, do not edit. --- > # --- ALSACONF verion 0.9.0 --- > alias char-major-116 snd > alias snd-card-0 snd-hdsp > alias char-major-14 soundcore > alias sound-slot-0 snd-card-0 > alias sound-service-0-0 snd-mixer-oss > alias sound-service-0-1 snd-seq-oss > alias sound-service-0-3 snd-pcm-oss > alias sound-service-0-8 snd-seq-oss > alias sound-service-0-12 snd-pcm-oss > options snd major=116 cards_limit=1 device_mode=0666 > options snd-hdsp index=0 > # --- END: Generated by ALSACONF, do not edit. --- > > > We then modify one line in the file to look like this: > > options snd major=116 cards_limit=2 device_mode=0666 > > > and we also do the following: > > <SNIP from the Planet> > add usb-midi and audio to the /etc/hotplug/blacklist file > So that the OSS audio and usb-midi modules are not automatically loaded > when the device reconnects after the firmware download. Add ``usb-midi'' > and ``audio'' in separate lines at the end of the list of blacklisted > modules in that file. > <End SNIP> > > I think, according to your info, that the problem is caused by not > having some sort of > > options snd-midiman index=1 > > line. That makes sense to me, except that I don't know what to put there > since there actually isn't a driver. The goal is to get the system to > make some devices in /dev/snd. This works fine on a cold boot, but fails > sometimes on a warm boot. (At least I think it does, since sometimes I > get pcmC1D0 when I have no pcmC0D0
the behavior depends on the order of booting. if the hotplug service is booted before the alsasound init script, hotplug will start the snd-usbaudio module, which will be assigned as the first empty device, i.e. device #0, unless you specify the index option. and afterwards, the alsasound script is started, and it results in the confliction of devices. setting an index option is one of the solutions. in this case, the first usb-audio/midi device will be forced to be assigned to #1. so, it's safe to start it beforehand. but, when we take a deeper look at this, we find another problem. the alsasound init script checks whether the ALSA was already started by checking the existence of /proc/asound directory. and, if hotplug started the usb-audio/midi before alsasound, this directory would be also created because the alsa core was started without help of alsasound init script, too. this leads to the skip of loading of any other soundcards, because alsasound will quit immediately. after all, a simple solution for this is to make sure that alsasound starts before hotplug. then, even the index option for snd-usbaudio wouldn't be necessary (in theory). in the above scenario, anyway, cards_limit must be changed. and i think it's a bit annoying. the attached patch will change the handling of cards_limit option. with the patch, the alsa won't restrict the number of cards per cards_limit option, but only limits the auto-probing via kmod. i.e. you can load more card modules even with cards_limit=1. i'd like to hear which behavior is preferable. ciao, Takashi
limit-check.dif
Description: Binary data
