Re: alsasound init script (Re: possible problems with rc6 aplay )

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Pedro Lopez-Cabanillas]

On Friday 20 December 2002 21:09, Clemens Ladisch wrote:
> Takashi Iwai wrote:
> > Mark Knecht wrote:
> > > I was wondering what would happen in this process if someone had two r
> > > three identical USB devices, like the MidiMan 2X2? OR also two
> > > identical cards like the RME HDSP 9652?
> >
> > when a module is loaded and two or more identical (or supported)
> > devices are connected, the module will initialize the all such devices
> > at once.
> >
> > for multiple devices, you can specify the options separated by commas,
> >
> > > It is important that the system recognize the same hardware as the same
> > > sound device every time the machine booted, and whether the machine is
> > > warm or cold booted.
> >
> > in the case of usb, it's not 100% sure, because it's anyway
> > hotpluggable.  but usually the order of probing is identical, so it's
> > ok.

The probing order is the same if you plug everytime the same device at the 
same USB bus/port. Hotplug agent also receives an environment variable,  
DEVICE=/proc/bus/usb/001/002 or something like this, being the last numbers 
the USB bus and device numbers.

> It is possible to force USB devices to a specific index with the vid/pid
> parameters for the vendor/product id, even when hotplugging.
> However, this won't work when you hotplug two identical devices (with the
> same product id).

The vid/pid parameters work well for me, as i have two USB MIDI devices from  
different vendors. It works regarding the plug order, or the USB port used. 
Perhaps another parameter like usbdev=001/002 or something else could be 
useful in case that someone has several identical devices?

Clemens, I remember that /proc/asound/cards returned this bus/device  
information for USB MIDI devices some time ago (rc3?), like it does for my SB 
128 PCI.

Regards,
Pedro

-- 
ALSA Library Bindings for Pascal
http://alsapas.alturl.com



-------------------------------------------------------
This SF.NET email is sponsored by:  The Best Geek Holiday Gifts!
Time is running out!  Thinkgeek.com has the coolest gifts for
your favorite geek.   Let your fingers do the typing.   Visit Now.
T H I N K G E E K . C O M        http://www.thinkgeek.com/sf/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Takashi Iwai]

At Fri, 20 Dec 2002 23:53:13 +0100,
Pedro Lopez-Cabanillas wrote:
> 
> Clemens, I remember that /proc/asound/cards returned this bus/device  
> information for USB MIDI devices some time ago (rc3?), like it does for my SB 
> 128 PCI.

it would be nice to provide a new generic proc file which shows the
low-level hardware information as the card number, the module name and
the PCI/ISA-PnP/USB/PCMCIA IDs like:

0 snd-ens1371 0x0123 0xABCD
1 snd-usb-audio 0xXXXX 0xYYYY


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Patrick Shirkey]

Takashi Iwai wrote:
> At Fri, 20 Dec 2002 23:53:13 +0100,
> Pedro Lopez-Cabanillas wrote:
> 
>>Clemens, I remember that /proc/asound/cards returned this bus/device  
>>information for USB MIDI devices some time ago (rc3?), like it does for my SB 
>>128 PCI.
> 
> 
> it would be nice to provide a new generic proc file which shows the
> low-level hardware information as the card number, the module name and
> the PCI/ISA-PnP/USB/PCMCIA IDs like:
> 
> 0 snd-ens1371 0x0123 0xABCD
> 1 snd-usb-audio 0xXXXX 0xYYYY
> 

Could you add to that the irq number?



-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Mark Knecht]

On Mon, 2002-12-16 at 07:23, Paul Davis wrote:
> >> that reminds me. the last version of the alsasound script that i saw
> >> did something very dangerous. it seemed to try to install *every*
> >> snd-card module it could find. if you have a system with an ISA bus,
> >> this can prove fatal to the system - many ISA device probes will kill
> >> the machine if the device is not present.
> > 
> >well, you can find that the alsasound script tries to load the modules
> >aliased as "snd-card-[0-9]", not the all snd-card-* modules.
> >remember that there is no module named as such.  that means, if such a
> >module is found, it was certainly configured by some means.
> 
> ah. sorry, i missed the -c on modprobe. i take it all back :(
> 
> --p

I wonder if this could have anything to do with a different problem I'm
seeing. I have a HDSP 9652 and a MidiMan 2X2 interface. The HDSP is
installed by alsaconf. The 2X2 is installed usign Fernando's
instructions from the Planet.

When I do a cold boot, the HDSP is always recognized first, and then the
MidiMan comes up as card 2, at least by reading the numbers of the
devices in /dev/snd. However, if I reboot, many times the system makes
the 2X2 card 1 and the HDSP card 2, and that breaks a lot of this
software.

What would cause this to happen and how could I stop it?

I have found that everything seems to work fine if I remember to unplug
the 2X2 when the reboot begins, but sometimes I don't remember and have
to go through one more boot cycle.

Cheers,
Mark



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Paul Davis]

>I wonder if this could have anything to do with a different problem I'm
>seeing. I have a HDSP 9652 and a MidiMan 2X2 interface. The HDSP is
>installed by alsaconf. The 2X2 is installed usign Fernando's
>instructions from the Planet.
>
>When I do a cold boot, the HDSP is always recognized first, and then the
>MidiMan comes up as card 2, at least by reading the numbers of the
>devices in /dev/snd. However, if I reboot, many times the system makes
>the 2X2 card 1 and the HDSP card 2, and that breaks a lot of this
>software.
>
>What would cause this to happen and how could I stop it?

set the snd_index parameter for each module in /etc/modules.conf. this
will force each module to use a particular card number every time.

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


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Mark Knecht]

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

Thanks,
Mark



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Takashi Iwai]

[-- Attachment #1: Type: text/plain, Size: 3755 bytes --]

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

[-- Attachment #2: limit-check.dif --]
[-- Type: application/octet-stream, Size: 1133 bytes --]

--- alsa-kernel/core/init.c	12 Jun 2002 10:21:00 -0000	1.9
+++ alsa-kernel/core/init.c	16 Jul 2002 12:11:37 -0000
@@ -67,11 +67,19 @@
 				idx = idx2;
 				break;
 			}
+		if (idx < 0 && snd_ecards_limit < SNDRV_CARDS)
+			/* for dynamically additional devices like hotplug:
+			 * increment the limit if still free slot exists.
+			 */
+			idx = snd_ecards_limit++;
 	} else if (idx < snd_ecards_limit) {
 		if (snd_cards_lock & (1 << idx))
 			idx = -1;	/* invalid */
-	}
-	if (idx < 0 || idx >= snd_ecards_limit) {
+	} else if (idx < SNDRV_CARDS)
+		snd_ecards_limit = idx + 1; /* increase the limit */
+	else
+		idx = -1;
+	if (idx < 0) {
 		write_unlock(&snd_card_rwlock);
 		if (idx >= snd_ecards_limit)
 			snd_printk(KERN_ERR "card %i is out of range (0-%i)\n", idx, snd_ecards_limit-1);
--- alsa-kernel/core/sound.c	23 May 2002 08:26:29 -0000	1.14
+++ alsa-kernel/core/sound.c	16 Jul 2002 12:13:03 -0000
@@ -81,7 +81,7 @@
 
 	if (snd_cards[card] != NULL)
 		return;
-	if (card < 0 || card >= snd_ecards_limit)
+	if (card < 0 || card >= snd_cards_limit)
 		return;
 	sprintf(str, "snd-card-%i", card);
 	request_module(str);

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Fernando Pablo Lopez-Lezcano]

On Tue, 2002-12-17 at 03:06, Takashi Iwai wrote:
> 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.
> > 
> >    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.
> 
> 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).

I think that in RedHat hotplug is not started as a service so we cannot
make sure that alsasound starts first (at least not easily - I have to
check again on the startup scripts to see what is done and when). 

It would be better to make the alsasound script more robust (and
independent of the startup order) and able to deal with partially loaded
modules, so instead of just checking for the /proc/asound directory it
would actually see what modules are already loaded and only load those
that are not. It does not look too easy, it seems that /proc/asound does
not provide a list of loaded modules (rather a list of cards that are
not associated with module names). 

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

That sounds reasonable. 
-- Fernando




-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Takashi Iwai]

At 17 Dec 2002 11:36:10 -0800,
Fernando Pablo Lopez-Lezcano wrote:
> 
> On Tue, 2002-12-17 at 03:06, Takashi Iwai wrote:
> > 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.
> > > 
> > >    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.
> > 
> > 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).
> 
> I think that in RedHat hotplug is not started as a service so we cannot
> make sure that alsasound starts first (at least not easily - I have to
> check again on the startup scripts to see what is done and when). 
 
hmm, then it's difficult to assume the order...
in most cases, hotplug is started at the fairly early stage of boot
sequences, because it supports also the fundamental devices such like
network.

> It would be better to make the alsasound script more robust (and
> independent of the startup order) and able to deal with partially loaded
> modules, so instead of just checking for the /proc/asound directory it
> would actually see what modules are already loaded and only load those
> that are not. It does not look too easy, it seems that /proc/asound does
> not provide a list of loaded modules (rather a list of cards that are
> not associated with module names). 
 
agreed.  a scenario i can imagine now is that the script just takes a
look at /proc/asound/cards and checks the numbers at the first column.
this should correspond to the card indices which have been already
loaded.  then the script will try to load the modules snd-card-X but
skip the numbers listed in the above...
i'll try to rewrite as this way.


> > 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.
> 
> That sounds reasonable. 

fine, does anybody see a drawback?


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Takashi Iwai]

At Wed, 18 Dec 2002 11:46:45 +0100,
I wrote:
> 
> > It would be better to make the alsasound script more robust (and
> > independent of the startup order) and able to deal with partially loaded
> > modules, so instead of just checking for the /proc/asound directory it
> > would actually see what modules are already loaded and only load those
> > that are not. It does not look too easy, it seems that /proc/asound does
> > not provide a list of loaded modules (rather a list of cards that are
> > not associated with module names). 
>  
> agreed.  a scenario i can imagine now is that the script just takes a
> look at /proc/asound/cards and checks the numbers at the first column.
> this should correspond to the card indices which have been already
> loaded.  then the script will try to load the modules snd-card-X but
> skip the numbers listed in the above...
> i'll try to rewrite as this way.

after reconsideration: it would be much simpler to create a new proc
file which shows the modules already loaded.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Mark Knecht]

On Wed, 2002-12-18 at 03:17, Takashi Iwai wrote:
> At Wed, 18 Dec 2002 11:46:45 +0100,
> I wrote:
> > 
> > > It would be better to make the alsasound script more robust (and
> > > independent of the startup order) and able to deal with partially loaded
> > > modules, so instead of just checking for the /proc/asound directory it
> > > would actually see what modules are already loaded and only load those
> > > that are not. It does not look too easy, it seems that /proc/asound does
> > > not provide a list of loaded modules (rather a list of cards that are
> > > not associated with module names). 
> >  
> > agreed.  a scenario i can imagine now is that the script just takes a
> > look at /proc/asound/cards and checks the numbers at the first column.
> > this should correspond to the card indices which have been already
> > loaded.  then the script will try to load the modules snd-card-X but
> > skip the numbers listed in the above...
> > i'll try to rewrite as this way.
> 
> after reconsideration: it would be much simpler to create a new proc
> file which shows the modules already loaded.
> 
I was wondering what would happen in this process if someone had two r
three identical USB devices, like the MidiMan 2X2? OR also two identical
cards like the RME HDSP 9652?

It is important that the system recognize the same hardware as the same
sound device every time the machine booted, and whether the machine is
warm or cold booted. 

The name I'm seeing linked in /dev/sound are possibly a bit too generic,
being just '2X2' and 'DSP'.

Just a thought.




-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Takashi Iwai]

At 18 Dec 2002 05:11:36 -0800,
Mark Knecht wrote:
> 
> On Wed, 2002-12-18 at 03:17, Takashi Iwai wrote:
> > At Wed, 18 Dec 2002 11:46:45 +0100,
> > I wrote:
> > > 
> > > > It would be better to make the alsasound script more robust (and
> > > > independent of the startup order) and able to deal with partially loaded
> > > > modules, so instead of just checking for the /proc/asound directory it
> > > > would actually see what modules are already loaded and only load those
> > > > that are not. It does not look too easy, it seems that /proc/asound does
> > > > not provide a list of loaded modules (rather a list of cards that are
> > > > not associated with module names). 
> > >  
> > > agreed.  a scenario i can imagine now is that the script just takes a
> > > look at /proc/asound/cards and checks the numbers at the first column.
> > > this should correspond to the card indices which have been already
> > > loaded.  then the script will try to load the modules snd-card-X but
> > > skip the numbers listed in the above...
> > > i'll try to rewrite as this way.
> > 
> > after reconsideration: it would be much simpler to create a new proc
> > file which shows the modules already loaded.
> > 
> I was wondering what would happen in this process if someone had two r
> three identical USB devices, like the MidiMan 2X2? OR also two identical
> cards like the RME HDSP 9652?
 
when a module is loaded and two or more identical (or supported)
devices are connected, the module will initialize the all such devices
at once.

for multiple devices, you can specify the options separated by commas,

	options snd-hdsp index=1,2,3 id="hdsp1","hdsp2","hdsp3"

if there is no index option given for a device, as mentioned before,
an empty slot is probed from the index 0.  thus, if you don't set any
index options for all modules, that's fine, except for that the order
of devices is not guaranteed.  (cards_limit option must be enough
large, or you need to apply my patch.)
for keeping the order of devices, giving the index option for each
device would be better.


> It is important that the system recognize the same hardware as the same
> sound device every time the machine booted, and whether the machine is
> warm or cold booted. 
 
in the case of usb, it's not 100% sure, because it's anyway
hotpluggable.  but usually the order of probing is identical, so it's
ok.


Takashi


-------------------------------------------------------
This SF.NET email is sponsored by:  The Best Geek Holiday Gifts!
Time is running out!  Thinkgeek.com has the coolest gifts for
your favorite geek.   Let your fingers do the typing.   Visit Now.
T H I N K G E E K . C O M        http://www.thinkgeek.com/sf/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Clemens Ladisch]

Takashi Iwai wrote:
> Mark Knecht wrote:
> > I was wondering what would happen in this process if someone had two r
> > three identical USB devices, like the MidiMan 2X2? OR also two identical
> > cards like the RME HDSP 9652?
>
> when a module is loaded and two or more identical (or supported)
> devices are connected, the module will initialize the all such devices
> at once.
>
> for multiple devices, you can specify the options separated by commas,
>
> > It is important that the system recognize the same hardware as the same
> > sound device every time the machine booted, and whether the machine is
> > warm or cold booted.
>
> in the case of usb, it's not 100% sure, because it's anyway
> hotpluggable.  but usually the order of probing is identical, so it's
> ok.

It is possible to force USB devices to a specific index with the vid/pid
parameters for the vendor/product id, even when hotplugging.
However, this won't work when you hotplug two identical devices (with the
same product id).


Clemens



-------------------------------------------------------
This SF.NET email is sponsored by:  The Best Geek Holiday Gifts!
Time is running out!  Thinkgeek.com has the coolest gifts for
your favorite geek.   Let your fingers do the typing.   Visit Now.
T H I N K G E E K . C O M        http://www.thinkgeek.com/sf/

Re: possible problems with rc6 aplay

[Takashi Iwai]

At Mon, 16 Dec 2002 08:49:35 -0500,
Paul Davis wrote:
> 
> >Martin,
> >   That might certainly be an answer. How would this amixer switch get
> >st in the first place? I wouldn't mind doing it by hand once as long as
> >it was then loaded after that.
> 
> what you want is a short startup script (typically in somewhere under
> /etc/rc.d, but unfortunately this varies somewhat from linux
> distribution to linux distribution). it would look like this:
> 
> 	#!/bin/sh
> 	
> 	HAMMERFALL=0 # change to match the card number of the
> 		     # Hammerfall, as shown in /proc/asound/cards
>         CLOCK_MODE=0 # auto-sync, the default condition.
> 	CLOCK_MODE_NAME="autosync"
> 
> 	case $1 in
> 	     start) if [ -f /some/path/to/this-host-is-master ] ; then
> 		        CLOCK_MODE=1
> 			CLOCK_MODE_NAME="master"
> 		    else
> 		        CLOCK_MODE=2
> 			CLOCK_MODE_NAME="word clock"
> 		    fi  
> 		    echo "Setting Hammerfall to $CLOCK_MODE_NAME mode ..."
> 		    amixer -c $HAMMERFALL cset \
> 			    iface=PCM,name='Sync Mode',numid=7 $CLOCK_MODE
>         esac			    
> 	exit 0
> 
> then, just create the file /some/path/to/this-host-is-master on one
> machine, and it will automatically set the Master switch when it boots
> up. the other machine will remain in AutoSync mode - if they are
> connected via word clock, you probably want to change that as well,
> using the same script.

the standard alsasound init script can call a card-dependent script
under /etc/alsa.d as the last initialization phase.  for example, you
can create the file above as /etc/alsa.d/rme9652 (with exec bit).  as
other examples, you can load the soundfont on this script for emu10k1
or sbawe.

many distributions use /etc/sysconfig/XXX file for a local
configuration, btw.  in this style, create a file
(e.g. /etc/sysconfig/rme9652) containing the variable definitions such
like:

	HAMMERFALL=0
	CLOCK_MODE=1
	CLOCK_MODE_NAME="master"

and call ". /etc/sysconfig/rme9652" at the beginning of the script.


ciao,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: possible problems with rc6 aplay

[Paul Davis]

>the standard alsasound init script can call a card-dependent script

that reminds me. the last version of the alsasound script that i saw
did something very dangerous. it seemed to try to install *every*
snd-card module it could find. if you have a system with an ISA bus,
this can prove fatal to the system - many ISA device probes will kill
the machine if the device is not present.

the alsasound script should assume, i think, that alsaconf has been
run, and that only modules listed in /etc/modules.conf or its
equivalent should be loaded.

--p


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

alsasound init script (Re: possible problems with rc6 aplay )

[Takashi Iwai]

At Mon, 16 Dec 2002 09:29:05 -0500,
Paul Davis wrote:
> 
> >the standard alsasound init script can call a card-dependent script
> 
> that reminds me. the last version of the alsasound script that i saw
> did something very dangerous. it seemed to try to install *every*
> snd-card module it could find. if you have a system with an ISA bus,
> this can prove fatal to the system - many ISA device probes will kill
> the machine if the device is not present.
 
well, you can find that the alsasound script tries to load the modules
aliased as "snd-card-[0-9]", not the all snd-card-* modules.
remember that there is no module named as such.  that means, if such a
module is found, it was certainly configured by some means.


ciao,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Paul Davis]

>> that reminds me. the last version of the alsasound script that i saw
>> did something very dangerous. it seemed to try to install *every*
>> snd-card module it could find. if you have a system with an ISA bus,
>> this can prove fatal to the system - many ISA device probes will kill
>> the machine if the device is not present.
> 
>well, you can find that the alsasound script tries to load the modules
>aliased as "snd-card-[0-9]", not the all snd-card-* modules.
>remember that there is no module named as such.  that means, if such a
>module is found, it was certainly configured by some means.

ah. sorry, i missed the -c on modprobe. i take it all back :(

--p


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/