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
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
