[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

[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

[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

Re: [Alsa-user] Re: [lack of] dynamic detection/loading of modules

[Fernando Pablo Lopez-Lezcano]

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

> > 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). 
> 
> alsasound script calls alsactl and card-specific scripts (if any).
> this should be avoided in the case of partial load.

Yes, I took care of executing them just for the cards that had been
loaded. 

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

That's what I'm doing, more or less. I'm including a copy of the
modified alsasound script I'm testing. Seems to be working fine so far. 

I think the sequencer driver part is wrong. I don't know what is
expected there (ie: multiple drivers?). I suspect I have to turn that
part of the code into a loop iterating over all sequencer drivers. 

-- Fernando


[-- Attachment #2: alsasound --]
[-- Type: text/x-sh, Size: 6911 bytes --]

#!/bin/bash
#
# alsasound     This shell script takes care of starting and stopping
#               the ALSA sound driver.
#
# This script requires /usr/sbin/alsactl and /usr/bin/aconnect programs
# from the alsa-utils package.
#
# Copyright (c) by Jaroslav Kysela <perex@suse.cz> 
#
#
#  This program is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.
#
#  This program is distributed in the hope that it will be useful,
#  but WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#  GNU General Public License for more details.
#
#  You should have received a copy of the GNU General Public License
#  along with this program; if not, write to the Free Software
#  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
#
#
# For RedHat 5.0+:
# chkconfig: 2345 87 14
# description: ALSA driver
#
# modified to visually fit into SuSE 6.0+ by Philipp Thomas <pthomas@suse.de>
# further improvements by Bernd Kaindl, Olaf Hering and Takashi Iwai.
# 
### BEGIN INIT INFO
# Provides:       alsasound
# Required-Start: $remote_fs
# Required-Stop: $remote_fs
# Default-Start:  2 3 5
# Default-Stop:
# Description:    Loading ALSA drivers and store/restore the current setting
### END INIT INFO

if [ -e /etc/rc.d/init.d/functions ] ; then
  # redhat function library
  redhat=1
  . /etc/rc.d/init.d/functions
fi

if [ -r /etc/rc.config ]; then
  . /etc/rc.config
  rc_warning="\033[33m\033[1m"
else
  rc_done="done"
  rc_warning=""
  rc_reset=""
fi

if [ x$START_ALSA != xno ]; then
  START_ALSA=yes
fi
if [ x$START_ALSA_SEQ != xno ]; then
  START_ALSA_SEQ=yes
fi

# Determine the base and follow a runlevel link name.
base=${0##*/}
link=${base#*[SK][0-9][0-9]}

# Force execution if not called by a runlevel directory.
test $link = $base && START_ALSA=yes
test "$START_ALSA" = yes || exit 0

alsactl=/usr/sbin/alsactl
asoundcfg=/etc/asound.state
aconnect=/usr/bin/aconnect
alsascrdir=/etc/alsa.d

function start() {
  #
  # insert all sound modules that are not already loaded
  #
  drivers=`/sbin/modprobe -c | \
    grep -E "^[[:space:]]*alias[[:space:]]+snd-card-[[:digit:]]" | \
    awk '{print $3}'`
  loaded=""
  for i in $drivers; do
    if [ "$i" != off ]; then
	is_loaded=`grep -c ^$i /proc/modules`
	if [ "$is_loaded" == "0" ]; then
	    loaded="$loaded $i"
	    if [ $redhat ] ; then
		action "Starting sound driver $i" /sbin/modprobe $i
	    else
		echo -n "Starting sound driver: $i "
		/sbin/modprobe $i
		echo -e "$rc_done"
	    fi
	else
	    if [ $redhat ] ; then
		echo "Sound driver $i is already loaded"
	    fi
	fi
    fi
  done
  #
  # insert sequencer modules that are not already loaded
  #
  if [ x"$START_ALSA_SEQ" = xyes -a -r /proc/asound/seq/drivers ]; then
    t=`cut -d , -f 1 /proc/asound/seq/drivers`
    if [ "x$t" != "x" ]; then
	loaded=`grep -c ^$t /proc/modules`
	if [ "$loaded" == "0" ]; then
	    if [ $redhat ] ; then
		action "Starting sequencer driver $t" /sbin/modprobe $t
	    else
		/sbin/modprobe $t
	    fi
        else
	    if [ $redhat ] ; then
		echo "Sequencer driver $t is already loaded"
	    fi
	fi
    fi
  fi
  #
  # restore driver settings
  #
  if [ -d /proc/asound ]; then
    if [ ! -r $asoundcfg ]; then
      echo "No mixer config in $asoundcfg, you have to unmute your card!"
    else
      if [ -x $alsactl ]; then
	if [ $redhat ] ; then
	    action "Restoring sound driver settings" $alsactl -f $asoundcfg restore
	else
	    $alsactl -f $asoundcfg restore
	fi
      else
	if [ $redhat ] ; then
	    echo -n "Sound driver: could not find alsactl"
	    failure "Finding alsactl" && echo
	else
	    echo -e "${rc_warning}ERROR: alsactl not found${rc_reset}"
	fi
      fi
    fi
  fi
  #
  # run card-dependent scripts only for drivers we loaded
  #
  for i in $loaded; do
    t=${i##snd-}
    if [ -x $alsascrdir/$t ]; then
	if [ $redhat ] ; then
	    action "Running $t script" $alsascrdir/$t
	else
	    $alsascrdir/$t
	fi
    fi
  done
  #
  # touch lockfile if lockdir exists
  #
  if [ -d /var/lock/subsys ] ; then
    touch /var/lock/subsys/alsasound
  fi
}

function terminate() {
  #
  # Kill processes holding open sound devices
  #
  # DEVS=`find /dev/ -follow -type c -maxdepth 1 -print 2>/dev/null | xargs ls -dils | grep "1*1[46]," | cut -d: -f2 | cut -d" " -f2; echo /proc/asound/dev/*`
  ossdevs="/dev/admmidi? /dev/adsp? /dev/amidi? /dev/audio* /dev/dmfm* \
     /dev/dmmidi? /dev/dsp* /dev/dspW* /dev/midi0? /dev/mixer? /dev/music \
     /dev/patmgr? /dev/sequencer* /dev/sndstat"
  alsadevs="/proc/asound/dev/*"
  fuser -k $ossdevs $alsadevs 2> /dev/null 1>/dev/null
  #
  # remove all sequencer connections if any
  #
  if [ -f /proc/asound/seq/clients -a -x $aconnect ]; then
    $aconnect --removeall
  fi
}

function stop() {
  #
  # store driver settings
  # [nando: we always initialize the driver to the default settings]
  #
  # if [ -x $alsactl ]; then
  #   $alsactl -f $asoundcfg store
  # else
  #   echo -n -e "${rc_warning}!!!alsactl not found!!!${rc_reset} "
  # fi
  #
  # remove all sound modules
  #
  /sbin/lsmod | grep -E "^snd" | grep -Ev "^(snd-page-alloc|snd-hammerfall-mem)" | while read line; do \
     /sbin/rmmod `echo $line | cut -d ' ' -f 1`; \
  done
  # remove the 2.2 soundcore module (if possible)
  /sbin/rmmod soundcore 2> /dev/null
  /sbin/rmmod gameport 2> /dev/null

  #
  # remove lockfile if lockdir exists
  #
  if [ -d /var/lock/subsys ] ; then
    rm -f /var/lock/subsys/alsasound
  fi
}

# See how we were called.
case "$1" in
  start)
        # Start driver if it isn't already up.
	if [ -d /proc/asound ]; then
	    echo "ALSA driver already running"
	fi
	start
	if [ $redhat ] ; then
	    if [ -d /proc/asound -a -d /var/lock/subsys ]; then
		touch /var/lock/subsys/alsasound
	    fi
	fi
        ;;
  stop)
        # Stop daemons.
	if [ -d /proc/asound ]; then
          echo -n "Shutting down sound driver"
	  terminate
	  stop
	  if [ $redhat ] ; then
	    if [ -d /var/lock/subsys ]; then
		rm -f /var/lock/subsys/alsasound
	    fi
	    success "sound driver stop" && echo
	  else
	    echo -e "$rc_done"
	  fi
	fi
        ;;
  restart|reload)
	$0 stop
	$0 start
	;;
  status)
        if [ -d /proc/asound ]; then
          echo -n "ALSA sound driver loaded."
        else
          echo -n "ALSA sound driver not loaded."
        fi
        echo
        ;;
  *)
        echo "Usage: alsasound {start|stop|restart|status}"
        exit 1
esac

exit 0

Re: [Alsa-user] Re: [lack of] dynamic detection/loading of modules

[Fernando Pablo Lopez-Lezcano]

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

> > alsasound script calls alsactl and card-specific scripts (if any).
> > this should be avoided in the case of partial load.
> 
> Yes, I took care of executing them just for the cards that had been
> loaded. 
> 
> > 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.
> 
> That's what I'm doing, more or less. I'm including a copy of the
> modified alsasound script I'm testing. Seems to be working fine so far. 
> 
> I think the sequencer driver part is wrong. I don't know what is
> expected there (ie: multiple drivers?). I suspect I have to turn that
> part of the code into a loop iterating over all sequencer drivers. 

It was wrong, of course... I'm including an updated script that is
apparently working fine. Takes into account multiple sequencer drivers
and executes scripts only for devices loaded while it runs. 

-- Fernando


[-- Attachment #2: alsasound --]
[-- Type: text/x-sh, Size: 7002 bytes --]

#!/bin/bash
#
# alsasound     This shell script takes care of starting and stopping
#               the ALSA sound driver.
#
# This script requires /usr/sbin/alsactl and /usr/bin/aconnect programs
# from the alsa-utils package.
#
# Copyright (c) by Jaroslav Kysela <perex@suse.cz> 
#
#
#  This program is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.
#
#  This program is distributed in the hope that it will be useful,
#  but WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#  GNU General Public License for more details.
#
#  You should have received a copy of the GNU General Public License
#  along with this program; if not, write to the Free Software
#  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
#
#
# For RedHat 5.0+:
# chkconfig: 2345 87 14
# description: ALSA driver
#
# modified to visually fit into SuSE 6.0+ by Philipp Thomas <pthomas@suse.de>
# further improvements by Bernd Kaindl, Olaf Hering and Takashi Iwai.
# 
### BEGIN INIT INFO
# Provides:       alsasound
# Required-Start: $remote_fs
# Required-Stop: $remote_fs
# Default-Start:  2 3 5
# Default-Stop:
# Description:    Loading ALSA drivers and store/restore the current setting
### END INIT INFO

if [ -e /etc/rc.d/init.d/functions ] ; then
  # redhat function library
  redhat=1
  . /etc/rc.d/init.d/functions
fi

if [ -r /etc/rc.config ]; then
  . /etc/rc.config
  rc_warning="\033[33m\033[1m"
else
  rc_done="done"
  rc_warning=""
  rc_reset=""
fi

if [ x$START_ALSA != xno ]; then
  START_ALSA=yes
fi
if [ x$START_ALSA_SEQ != xno ]; then
  START_ALSA_SEQ=yes
fi

# Determine the base and follow a runlevel link name.
base=${0##*/}
link=${base#*[SK][0-9][0-9]}

# Force execution if not called by a runlevel directory.
test $link = $base && START_ALSA=yes
test "$START_ALSA" = yes || exit 0

alsactl=/usr/sbin/alsactl
asoundcfg=/etc/asound.state
aconnect=/usr/bin/aconnect
alsascrdir=/etc/alsa.d

function start() {
  #
  # insert all sound modules that are not already loaded
  #
  drivers=`/sbin/modprobe -c | \
    grep -E "^[[:space:]]*alias[[:space:]]+snd-card-[[:digit:]]" | \
    awk '{print $3}'`
  loaded=""
  for i in $drivers; do
    if [ "$i" != off ]; then
	is_loaded=`grep -c ^$i /proc/modules`
	if [ "$is_loaded" == "0" ]; then
	    if [ $redhat ] ; then
		action "Starting sound driver $i" /sbin/modprobe $i
		if [ "$?" == "0" ]; then loaded="$loaded $i" ; fi
	    else
		echo -n "Starting sound driver: $i "
		/sbin/modprobe $i
		if [ "$?" == "0" ]; then loaded="$loaded $i" ; fi
		echo -e "$rc_done"
	    fi
	else
	    if [ $redhat ] ; then
		echo "Sound driver $i is already loaded"
	    fi
	fi
    fi
  done
  #
  # insert sequencer modules that are not already loaded
  #
  if [ x"$START_ALSA_SEQ" = xyes -a -r /proc/asound/seq/drivers ]; then
    seq_drivers=`cut -d , -f 1 /proc/asound/seq/drivers`
    for i in $seq_drivers; do
	is_loaded=`grep -c ^$i /proc/modules`
	if [ "$is_loaded" == "0" ]; then
	    if [ $redhat ] ; then
		action "Starting sequencer driver $i" /sbin/modprobe $i
	    else
		/sbin/modprobe $i
	    fi
	else
	    if [ $redhat ] ; then
		echo "Sequencer driver $i is already loaded"
	    fi
	fi
    done
  fi
  #
  # restore driver settings
  #
  if [ -d /proc/asound ]; then
    if [ ! -r $asoundcfg ]; then
      echo "No mixer config in $asoundcfg, you have to unmute your card!"
    else
      if [ -x $alsactl ]; then
	if [ $redhat ] ; then
	    action "Restoring sound driver settings" $alsactl -f $asoundcfg restore
	else
	    $alsactl -f $asoundcfg restore
	fi
      else
	if [ $redhat ] ; then
	    echo -n "Sound driver: could not find alsactl"
	    failure "Finding alsactl" && echo
	else
	    echo -e "${rc_warning}ERROR: alsactl not found${rc_reset}"
	fi
      fi
    fi
  fi
  #
  # run card-dependent scripts only for drivers we loaded
  #
  for i in $loaded; do
    t=${i##snd-}
    if [ -x $alsascrdir/$t ]; then
	if [ $redhat ] ; then
	    action "Running $t script" $alsascrdir/$t
	else
	    $alsascrdir/$t
	fi
    fi
  done
  #
  # touch lockfile if lockdir exists
  #
  if [ -d /var/lock/subsys ] ; then
    touch /var/lock/subsys/alsasound
  fi
}

function terminate() {
  #
  # Kill processes holding open sound devices
  #
  # DEVS=`find /dev/ -follow -type c -maxdepth 1 -print 2>/dev/null | xargs ls -dils | grep "1*1[46]," | cut -d: -f2 | cut -d" " -f2; echo /proc/asound/dev/*`
  ossdevs="/dev/admmidi? /dev/adsp? /dev/amidi? /dev/audio* /dev/dmfm* \
     /dev/dmmidi? /dev/dsp* /dev/dspW* /dev/midi0? /dev/mixer? /dev/music \
     /dev/patmgr? /dev/sequencer* /dev/sndstat"
  alsadevs="/proc/asound/dev/*"
  fuser -k $ossdevs $alsadevs 2> /dev/null 1>/dev/null
  #
  # remove all sequencer connections if any
  #
  if [ -f /proc/asound/seq/clients -a -x $aconnect ]; then
    $aconnect --removeall
  fi
}

function stop() {
  #
  # store driver settings
  # [nando: we always initialize the driver to the default settings]
  #
  # if [ -x $alsactl ]; then
  #   $alsactl -f $asoundcfg store
  # else
  #   echo -n -e "${rc_warning}!!!alsactl not found!!!${rc_reset} "
  # fi
  #
  # remove all sound modules
  #
  /sbin/lsmod | grep -E "^snd" | grep -Ev "^(snd-page-alloc|snd-hammerfall-mem)" | while read line; do \
     /sbin/rmmod `echo $line | cut -d ' ' -f 1`; \
  done
  # remove the 2.2 soundcore module (if possible)
  /sbin/rmmod soundcore 2> /dev/null
  /sbin/rmmod gameport 2> /dev/null

  #
  # remove lockfile if lockdir exists
  #
  if [ -d /var/lock/subsys ] ; then
    rm -f /var/lock/subsys/alsasound
  fi
}

# See how we were called.
case "$1" in
  start)
        # Start driver if it isn't already up.
	if [ -d /proc/asound ]; then
	    echo "ALSA driver already running"
	fi
	start
	if [ $redhat ] ; then
	    if [ -d /proc/asound -a -d /var/lock/subsys ]; then
		touch /var/lock/subsys/alsasound
	    fi
	fi
        ;;
  stop)
        # Stop daemons.
	if [ -d /proc/asound ]; then
          echo -n "Shutting down sound driver"
	  terminate
	  stop
	  if [ $redhat ] ; then
	    if [ -d /var/lock/subsys ]; then
		rm -f /var/lock/subsys/alsasound
	    fi
	    success "sound driver stop" && echo
	  else
	    echo -e "$rc_done"
	  fi
	fi
        ;;
  restart|reload)
	$0 stop
	$0 start
	;;
  status)
        if [ -d /proc/asound ]; then
          echo -n "ALSA sound driver loaded."
        else
          echo -n "ALSA sound driver not loaded."
        fi
        echo
        ;;
  *)
        echo "Usage: alsasound {start|stop|restart|status}"
        exit 1
esac

exit 0

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: [Alsa-user] [lack of] dynamic detection/loading of modules

[Jaroslav Kysela]

On Wed, 26 Feb 2003, Ivica Bukvic wrote:

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

Note that the problem is already solveable with a nice way. The SuSE uses
this hotplug script:

-------------------------
#!/bin/bash
#
# /etc/hotplug/usb/alsasound
#
# Sets up newly plugged in USB audio/MIDI devices.
#

if [ "$INTERFACE" != "" ]; then
    IFS=/
    set $INTERFACE ''
    usb_bInterfaceClass=$1
    usb_bInterfaceSubClass=$2
    usb_bInterfaceProtocol=$3
    IFS="$DEFAULT_IFS"
fi

function add_alsa () {
    # check alsa is already running
    if [ ! -d /proc/asound ]; then
	# start alsasound script, so that static devices are properly loaded
	echo "Starting ALSA..."
	/etc/init.d/alsasound start >/dev/null 2>&1
    fi
    /sbin/modprobe snd-usb-audio
    if [ "$usb_bInterfaceSubClass" != "0x01" ]; then
      /sbin/modprobe snd-usb-midi
    fi
}

function remove_alsa () {
    /sbin/modprobe -r snd-usb-midi
    /sbin/modprobe -r snd-usb-audio
}

case "$ACTION" in
add)
  add_alsa
  ;;
remove)
  remove_alsa
  ;;
esac
-----------------------

So, if no static ALSA drivers are loaded, load them before usb module is
inserted. Nice way to solve all your problems.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

RE: [Alsa-user] [lack of] dynamic detection/loading of modules

[Ivica Bukvic]

I presume I need to blacklist the snd-usb-audio/midi in the
/etc/hotplug/blacklist for this to work?

Also, do I need to make any other changes or as long as I put this
script into the /etc/hotplug/ dir I am set?

Thanks for the great script!

(is this going to become a standard part of the alsa driver? I sure hope
so :-)

Ico



> Note that the problem is already solveable with a nice way. The SuSE
uses
> this hotplug script:
> 
> -------------------------
> #!/bin/bash
> #
> # /etc/hotplug/usb/alsasound
> #
> # Sets up newly plugged in USB audio/MIDI devices.
> #
> 
> if [ "$INTERFACE" != "" ]; then
>     IFS=/
>     set $INTERFACE ''
>     usb_bInterfaceClass=$1
>     usb_bInterfaceSubClass=$2
>     usb_bInterfaceProtocol=$3
>     IFS="$DEFAULT_IFS"
> fi
> 
> function add_alsa () {
>     # check alsa is already running
>     if [ ! -d /proc/asound ]; then
> 	# start alsasound script, so that static devices are properly
loaded
> 	echo "Starting ALSA..."
> 	/etc/init.d/alsasound start >/dev/null 2>&1
>     fi
>     /sbin/modprobe snd-usb-audio
>     if [ "$usb_bInterfaceSubClass" != "0x01" ]; then
>       /sbin/modprobe snd-usb-midi
>     fi
> }
> 
> function remove_alsa () {
>     /sbin/modprobe -r snd-usb-midi
>     /sbin/modprobe -r snd-usb-audio
> }
> 
> case "$ACTION" in
> add)
>   add_alsa
>   ;;
> remove)
>   remove_alsa
>   ;;
> esac
> -----------------------
> 
> So, if no static ALSA drivers are loaded, load them before usb module
is
> inserted. Nice way to solve all your problems.
> 
> 						Jaroslav
> 
> -----
> Jaroslav Kysela <perex@suse.cz>
> Linux Kernel Sound Maintainer
> ALSA Project, SuSE Labs




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: RE: [Alsa-user] [lack of] dynamic detection/loading of modules

[Takashi Iwai]

At Thu, 27 Feb 2003 08:05:49 -0500,
Ivica Bukvic wrote:
> 
> I presume I need to blacklist the snd-usb-audio/midi in the
> /etc/hotplug/blacklist for this to work?

yes.  the script there was a bit old and now you don't need
load/unload snd-usb-midi.
 
> Also, do I need to make any other changes or as long as I put this
> script into the /etc/hotplug/ dir I am set?
> 
> Thanks for the great script!
> 
> (is this going to become a standard part of the alsa driver? I sure hope
> so :-)

well, this hotplug stuff depends on the distribution...

in the of suse distro, the script is in /etc/hotplug/usb.  this script
is called from the user-map file, /etc/hotplug/usb/alsasound.usermap,
which has basically the same as /lib/modules/XXX/modules.usbmap but
snd-usb-audio is replaced with alsasound (the script name).


Takashi


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: Re: [Alsa-user] [lack of] dynamic detection/loading of modules

[Fernando Pablo Lopez-Lezcano]

> Note that the problem is already solveable with a nice way. The SuSE uses
> this hotplug script:
> 
> -------------------------
> #!/bin/bash
> #
> # /etc/hotplug/usb/alsasound
> #
> # Sets up newly plugged in USB audio/MIDI devices.
> #
> 
> if [ "$INTERFACE" != "" ]; then
>     IFS=/
>     set $INTERFACE ''
>     usb_bInterfaceClass=$1
>     usb_bInterfaceSubClass=$2
>     usb_bInterfaceProtocol=$3
>     IFS="$DEFAULT_IFS"
> fi
> 
> function add_alsa () {
>     # check alsa is already running
>     if [ ! -d /proc/asound ]; then
> 	# start alsasound script, so that static devices are properly loaded
> 	echo "Starting ALSA..."
> 	/etc/init.d/alsasound start >/dev/null 2>&1
>     fi
>     /sbin/modprobe snd-usb-audio

If I have snd-usb-audio configured in modules.conf snd-usb-audio will
already be loaded at this point (I think). 

>     if [ "$usb_bInterfaceSubClass" != "0x01" ]; then
>       /sbin/modprobe snd-usb-midi
>     fi
> }
> 
> function remove_alsa () {
>     /sbin/modprobe -r snd-usb-midi
>     /sbin/modprobe -r snd-usb-audio
> }
> 
> case "$ACTION" in
> add)
>   add_alsa
>   ;;
> remove)
>   remove_alsa
>   ;;
> esac
> -----------------------
> 
> So, if no static ALSA drivers are loaded, load them before usb module is
> inserted. Nice way to solve all your problems.

Very nice! The only downside I see is that you can no longer disable the
script. If you disable it for all run levels it will run anyway if you
plug in a usb audio device (which probably makes sense for the usb
device itself), and will try to start all non-usb audio devices. Maybe
SuSE takes this into account as well, I don't know. 

Does this also need a usb.usermap entry(ies) to trigger the script?

What happens with multiple usb audio/midi devices? They all share one
snd-usb-audio module. What happens when I unplug one device? The module
gets removed and all devices that are still plugged in are orphaned?

-- Fernando




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