init script with hotplug & usb audio

init script with hotplug & usb audio

[Duncan Sands]

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?

Duncan.


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

Re: init script with hotplug & usb audio

[Tim Goetze]

Duncan Sands wrote:

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

you can change the order in which init scripts are run,
read your distribution's documentation. on debian, this
would mean renaming one of /etc/rc2.d/SXXalsasound or
/etc/rc2.d/SXXhotplug -- XX are two-digit numbers that
decide over the running order, the higher the later.

hth, tim




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

Re: init script with hotplug & usb audio

[Duncan Sands]

On Thursday 26 September 2002 12:40, Tim Goetze wrote:
> Duncan Sands wrote:
> >(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.
>
> you can change the order in which init scripts are run,
> read your distribution's documentation. on debian, this
> would mean renaming one of /etc/rc2.d/SXXalsasound or
> /etc/rc2.d/SXXhotplug -- XX are two-digit numbers that
> decide over the running order, the higher the later.

Sure.  On the other hand, if I plug in the usb audio device
after the init script has been run, who will restore mixer
settings for it?  In short, the solution you suggest will work
fine in most cases, but in the long term more cooperation
between the init script and hotplugging scripts will be needed.

All the best,

Duncan.


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

Re: init script with hotplug & usb audio

[Takashi Iwai]

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. 


Takashi


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

Re: init script with hotplug & usb audio

[Duncan Sands]

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.

In the short term a quick hack will do of course.

Thanks for your help,

Duncan.


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

Re: init script with hotplug & usb audio

[Takashi Iwai]

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

Re: init script with hotplug & usb audio

[Duncan Sands]

On Friday 27 September 2002 19:53, Takashi Iwai wrote:
> 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.

Another point to keep in mind here, is that a lot of people are now
using journaled filesystems, and may just turn off the computer
without shutting down.  You could say that they deserve what they
get, but I'm not so sure.  Imagine someone using alsamixer to change
mixer settings.  They quit alsamixer then turn off the machine.  Are
they wrong to expect the mixer settings to still be there on reboot?
After all, they "saved the settings" when they left alsamixer didn't they?

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

Duncan.


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

Re: init script with hotplug & usb audio

[Takashi Iwai]

At Mon, 30 Sep 2002 09:55:14 +0200,
Duncan Sands wrote:
> 
> On Friday 27 September 2002 19:53, Takashi Iwai wrote:
> > 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.
> 
> Another point to keep in mind here, is that a lot of people are now
> using journaled filesystems, and may just turn off the computer
> without shutting down.  You could say that they deserve what they
> get, but I'm not so sure.  Imagine someone using alsamixer to change
> mixer settings.  They quit alsamixer then turn off the machine.  Are
> they wrong to expect the mixer settings to still be there on reboot?

yes.  the infromation will be lost.

> After all, they "saved the settings" when they left alsamixer didn't they?

no, the setting is on memory, thus not saved when you turn the power
off.  he can run "alsactl store" manually (or write a equivalent
wrapper script for alsamixer) instead.
but this should not be standard, i think.


Takashi


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

Re: init script with hotplug & usb audio

[Duncan Sands]

> > Another point to keep in mind here, is that a lot of people are now
> > using journaled filesystems, and may just turn off the computer
> > without shutting down.  You could say that they deserve what they
> > get, but I'm not so sure.  Imagine someone using alsamixer to change
> > mixer settings.  They quit alsamixer then turn off the machine.  Are
> > they wrong to expect the mixer settings to still be there on reboot?
>
> yes.  the infromation will be lost.
>
> > After all, they "saved the settings" when they left alsamixer didn't
> > they?
>
> no, the setting is on memory, thus not saved when you turn the power
> off.  he can run "alsactl store" manually (or write a equivalent
> wrapper script for alsamixer) instead.
> but this should not be standard, i think.

Too costly?

Just to be clear: I know that the mixer information will be lost, I was just trying
to point out that the current behaviour is not what people might reasonably expect.

Ciao,

Duncan.


-------------------------------------------------------
This sf.net email is sponsored by: DEDICATED SERVERS only $89!
Linux or FreeBSD, FREE setup, FAST network. Get your own server 
today at http://www.ServePath.com/indexfm.htm