All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Duncan Sands <baldrick@wanadoo.fr>
Cc: alsa-devel@lists.sourceforge.net
Subject: Re: init script with hotplug & usb audio
Date: Fri, 27 Sep 2002 19:53:02 +0200	[thread overview]
Message-ID: <s5hk7l7l3pd.wl@alsa2.suse.de> (raw)
In-Reply-To: <200209270908.41909.baldrick@wanadoo.fr>

At Fri, 27 Sep 2002 09:08:41 +0200,
Duncan Sands wrote:
> 
> On Thursday 26 September 2002 13:49, Takashi Iwai wrote:
> > At Thu, 26 Sep 2002 10:20:25 +0200,  Duncan Sands wrote:
> > > I have a usb webcam with audio plugged into my computer,
> > > and a cs46xx sound card inside.
> > >
> > > When I boot the following sequence occurs:
> > >
> > > (1) the hotplug subsytem is started.  This automatically
> > > loads the snd-usb-audio module and the modules it
> > > depends on.  In particular /proc/asound/ is created.
> > >
> > > (2) the alsasound init script is run.  It detects that
> > > /proc/asound/ exists, and exits at once.  In particular
> > > it does not restore mixer levels for the cs46xx card.
> > >
> > > I solved this by commenting out the check for /proc/asound/
> > > in the init script.  The problem goes deeper though, especially
> > > when things like usb audio devices are around, which can be
> > > hotplugged: maybe sound card modules should really be calling
> > > the hotplug subsystem when they are initialize.  The hotplug
> > > script would then restore mixer settings etc...
> > >
> > > Thoughts?
> >
> > i solved like the following:
> >
> > - add snd-usb-* (and oss audio module) to hotplug's blacklist
> >   to avoid to load them from the modules.usermap.
> > - add a usermap for the usb audio devices to call its own start-up
> >   script.  the script starts the alsasound init script inside before
> >   loading the snd-usb-audio module (if no /proc/asound exists), so
> >   that it asssures that the normal PCI devices are assigned prior to
> >   usb devices.
> 
> Thanks for the info.  I still think it's a bandaid though: the real problem
> is that the logic in the init script is broken.  Anything that causes modules
> to be loaded before the init script is run breaks the script, as far as I can
> see.  For example: compiling into the kernel, i.e. not as modules ; using
> hardware detection software that autoloads sound card drivers ; using usb
> audio...  In these cases /proc/asound will exist when the init script is run,
> and mixer settings will not be restored, card specific scripts will not be run etc.
> 
> In the long term (2.6 kernel) I am imagining the following:
> 
> (1) the init script just loads modules.
> (2) when modules are loaded, whether for a pci card, a usb one whatever,
> the hotplug subsystem is called: it restores mixer settings for the card and
> runs card specific scripts.

except for the check of /proc/asound, the hotplug problem can be
sorted to the following:

1. hotplug may be called before alsa init script.

2. hotplug needs to manage the mixer configuration of plugged /
   unplugged devices dynamically.

3. alsa initscript itself should be independent from hotplug.

they are not all but certainly a major part of the problems.


the first one is not easy, because the network devices can belong to
hotplug, too.  the scenario is like this:
  many alsa files are located under /usr
    -> a networkfs (e.g. NFS) is required before the alsa service
      -> the network must be initialized in prior
        -> the network base = hotplug is needed to run before alsa!

the second problem is also tough.
alsa driver needs to access the device to get the current mixer
values, but at the remove callback of hotplug, the device was actually
unplugged...  probably implementing cache would be necessary.

the third one is obvious.
i don't think it's good to let hotplug initialize the pci cards, too.
for example, if i don't have any usb devices, i'd like to remove
hotplug.  but if alsa initscript rely on the hotplug stuff, i cannot
do that.  that's bad.

well, still many obstacles ahead.
i'd love to see a perfect solution :)


Takashi


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

  reply	other threads:[~2002-09-27 17:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-26  8:20 init script with hotplug & usb audio Duncan Sands
2002-09-26 10:40 ` Tim Goetze
2002-09-27  7:11   ` Duncan Sands
2002-09-26 11:49 ` Takashi Iwai
2002-09-27  7:08   ` Duncan Sands
2002-09-27 17:53     ` Takashi Iwai [this message]
2002-09-30  7:55       ` Duncan Sands
2002-09-30 10:04         ` Takashi Iwai
2002-10-01  6:46           ` Duncan Sands

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5hk7l7l3pd.wl@alsa2.suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=baldrick@wanadoo.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.