[lack of] dynamic detection/loading of modules

[lack of] dynamic detection/loading of modules

[Ivica Bukvic]

Hi all,

After several correspondence between the CCRMA's Linux audio guru
Fernando and myself, I realized that Alsa really needs (as Fernando has
pointed out) list of modules currently loaded that would enable users to
simply plug in devices as needed and then have them immediately
recognized by Alsa without having to restart the alsasound server (or
perhaps have it restart automatically -- although now that I think of
it, this would be a hack-like approach that would wreak havoc among the
open apps talking to the audio resources at the time of its restart).

The typical example of problems that arise due to fact that this is not
available is with the Midisport 2x2 USB interface (something that is
applicable to any other hot-pluggable audio/midi interface).

Scenario 1:

If one enables loading of the Midisport 2x2 interface at boot time, then
the device loads before the actual soundcard (since alsasound service
starts after the USB service -- something that is apparently not
configurable). This results in an absent /dev/dsp (since midisport is
the default audio device and it has no audio capabilities) and a
hardlock if pd is spawned having Midisport being the 1st audio device
(and possibly a plethora of other, yet-to-be-discovered side-effects).
Having index values in modules.conf does not solve the problem, since
USB still starts before Alsasound does, and therefore USB hw is to the
best of my knowledge unaffected by it. The only solution is to hook-up
your USB equipment after the alsasound service starts (this is ok, but
not acceptable as a 100% user-friendly experience, since one that does
not know of this issue, such as myself a week ago, ends up crashing the
machine X times before realizing the problem, and that is if they ever
get to realize it -- I consider myself relatively Linux/Alsa literate,
and yet even I was feeling lost there for a while).

Scenario 2:

On the other hand if one blacklists loading of the snd-usb-midi at the
moment that Midisport 2x2 is detected (at boot-time) in order to have
Alsa configure itself properly through the modules.conf script
afterwards, this means that if one does not plug in the Midisport 2x2
before alsasound service starts (at boot-time), they are forced to
restart alsasound service in order to have their USB hw functional
(which may again wreak havoc on the open audio apps using audio
resources and furthermore requires relatively good knowledge of the
underlying problem as well as the concept of Linux services etc.).


Both of the situations are apparently unacceptable from an average
end-user standpoint since they imply that the end-user needs to know
these quirks in order to have basic (ok, not-so-basic :-) Alsa's
functionality.

Here's the excerpt from Fernando's comments which suggest a potentially
easy fix to the problem, something that would make Alsa a _lot_ more
user-friendly.

<quote>

"The proper fix to all this problem would be to modify the alsasound
startup script to be able to load the missing modules (ie: start a
partially started module load). There was a thread in one of the mailing
lists about this and to do it cleanly it would be nice to have available
in /proc/asound the list of modules currently loaded. That is not
available today (I think Takashi said he might add that)."

<end-quote>

Fernando mentions that there was already a thread on this issue and that
Takashi generously offered to do this at some point (and I am sure that
he's busy already as it is). However, it seems that this should be
something that needs more urgent attention, especially now that we have
seen a rapid increase in support of hot-pluggable audio hardware
(usb/pcmcia, and hopefully soon the firewire stuff).

I am posting this not to flame, but rather to expose the issue since a
lot of other users out there have experienced aforementioned problems,
but are not aware of the fact that there is no absolute fix for it. I am
also posting this in hopes that doing so will expedite this problem's
resolution, since its existence definitely limits Alsa's
user-friendliness (and hence perhaps its faster adoption).

I am not sure how OSS stands on this issue, but then again that should
not matter. Alsa is trying to raise the bar in the Linux audio quality
and this is definitely one of important usability issues that require
(IMHO) urgent attention.

Thank you! Sincerely,

Ivica Ico Bukvic, composer, multimedia sculptor,
programmer, webmaster & computer consultant 
http://meowing.ccm.uc.edu/~ico 
============================ 
"To be or not to be" - Shakespeare
"To be is to do"     - Socrates
"To do is to be"     - Sartre
"Do be do be do"     - Sinatra
"2b || ! 2b"         - ?
"I am"               - God




-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp

Re: [lack of] dynamic detection/loading of modules

[Paul Davis]

>lists about this and to do it cleanly it would be nice to have available
>in /proc/asound the list of modules currently loaded. That is not
>available today (I think Takashi said he might add that)."

cat /proc/modules | grep '^snd'



-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp

RE: [lack of] dynamic detection/loading of modules

[Ivica Bukvic]

> cat /proc/modules | grep '^snd'

Thanks for the reply. A couple of questions:

Where do you put this?

How do you trigger it automatically upon connection of a hot-pluggable
hw (if the stuff is blacklisted)?

How can we make this user-friendly? (i.e. no user interaction -> plug
'n' use).

Ico



-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp

Re: [lack of] dynamic detection/loading of modules

[Fernando Pablo Lopez-Lezcano]

> >lists about this and to do it cleanly it would be nice to have available
> >in /proc/asound the list of modules currently loaded. That is not
> >available today (I think Takashi said he might add that)."
> 
> cat /proc/modules | grep '^snd'

This relies in an (AFAIK) unenforceable convention (all modules that
start with "snd" are alsa modules). I think the information has to come
from within the alsa driver, or from some place that actually knows that
the module _is_ an alsa module. IMHO a name is not enough. 

-- Fernando




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

Re: [lack of] dynamic detection/loading of modules

[Takashi Iwai]

At 27 Feb 2003 12:35:00 -0800,
Fernando Pablo Lopez-Lezcano wrote:
> 
> > >lists about this and to do it cleanly it would be nice to have available
> > >in /proc/asound the list of modules currently loaded. That is not
> > >available today (I think Takashi said he might add that)."
> > 
> > cat /proc/modules | grep '^snd'
> 
> This relies in an (AFAIK) unenforceable convention (all modules that
> start with "snd" are alsa modules). I think the information has to come
> from within the alsa driver, or from some place that actually knows that
> the module _is_ an alsa module. IMHO a name is not enough. 

ok, i added the code.
the cvs version shows the list of modules on /proc/asound/modules.


Takashi


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

Re: [lack of] dynamic detection/loading of modules

[Fernando Pablo Lopez-Lezcano]

> > > >lists about this and to do it cleanly it would be nice to have available
> > > >in /proc/asound the list of modules currently loaded. That is not
> > > >available today (I think Takashi said he might add that)."
> > > 
> > > cat /proc/modules | grep '^snd'
> > 
> > This relies in an (AFAIK) unenforceable convention (all modules that
> > start with "snd" are alsa modules). I think the information has to come
> > from within the alsa driver, or from some place that actually knows that
> > the module _is_ an alsa module. IMHO a name is not enough. 
> 
> ok, i added the code.
> the cvs version shows the list of modules on /proc/asound/modules.

Thanks! I started working on differentiating in the alsasound alsa
startup script between a full start (all modules are loaded when
alsasound executes) and a partial start (some of the modules are already
loaded when alsasound executes and it has to load the rest). 

The first naive question is: do we actually need to differenciate?
Apparently modprobe is happy to be given the name of a module that is
already loaded, as far as I can tell it does not try to load it again
(man modprobe does not say anything about this case that I can see). 

Apparently we could just dispense with the [ -d /proc/asound ] test in
alsasound and always load (or reload) the modules... or maybe just print
a warning when part of alsa has already been started before alsasound
executes. Surely it cannot be that easy :-) What am I missing?

-- Fernando




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: [lack of] dynamic detection/loading of modules

[Fernando Pablo Lopez-Lezcano]

> > >lists about this and to do it cleanly it would be nice to have available
> > >in /proc/asound the list of modules currently loaded. That is not
> > >available today (I think Takashi said he might add that)."
> > 
> > cat /proc/modules | grep '^snd'

I wrote this:

> This relies in an (AFAIK) unenforceable convention (all modules that
> start with "snd" are alsa modules). I think the information has to come
> from within the alsa driver, or from some place that actually knows that
> the module _is_ an alsa module. IMHO a name is not enough. 

True, but I was wrong nevertheless. For the proposed use your solution
works fine because we already know the name of the alsa module we want
to check for (DOH!!!). 

-- Fernando




-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com

Re: [lack of] dynamic detection/loading of modules

[Takashi Iwai]

At 04 Mar 2003 19:01:24 -0800,
Fernando Pablo Lopez-Lezcano wrote:
> 
> > > > >lists about this and to do it cleanly it would be nice to have available
> > > > >in /proc/asound the list of modules currently loaded. That is not
> > > > >available today (I think Takashi said he might add that)."
> > > > 
> > > > cat /proc/modules | grep '^snd'
> > > 
> > > This relies in an (AFAIK) unenforceable convention (all modules that
> > > start with "snd" are alsa modules). I think the information has to come
> > > from within the alsa driver, or from some place that actually knows that
> > > the module _is_ an alsa module. IMHO a name is not enough. 
> > 
> > ok, i added the code.
> > the cvs version shows the list of modules on /proc/asound/modules.
> 
> Thanks! I started working on differentiating in the alsasound alsa
> startup script between a full start (all modules are loaded when
> alsasound executes) and a partial start (some of the modules are already
> loaded when alsasound executes and it has to load the rest). 
> 
> The first naive question is: do we actually need to differenciate?
> Apparently modprobe is happy to be given the name of a module that is
> already loaded, as far as I can tell it does not try to load it again
> (man modprobe does not say anything about this case that I can see). 
> 
> Apparently we could just dispense with the [ -d /proc/asound ] test in
> alsasound and always load (or reload) the modules... or maybe just print
> a warning when part of alsa has already been started before alsasound
> executes. Surely it cannot be that easy :-) What am I missing?

alsasound script calls alsactl and card-specific scripts (if any).
this should be avoided in the case of partial load.

IIRC, modprobe returns 0 even if called with the existing module.
(if the load failed, it returns 255, btw).
thus, we cannot check this only from the return value of modprobe.
instead we need to grep /proc/asound/modules for that module.


Takashi


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