27 Feb
2009
27 Feb
'09
12:38 p.m.
To be more specific I know that you still have to compile these
modules, unless you decide to make them part of the kernel. If you
build an RT kernel to be used for audio there is really no reason (or
?) why you should make modules of things like snd-seq, snd-pcm, etc,
i.e. "modules" not depending on specific hardware, just make them part
of the kernel.
The tedious process is to find out what hardware dependent modules to
use, in order to make them part of the "solution". The non-hardware
dependent modules to include should be determined once, and when first
entered into the config you should be done :)
With a scheme like this the process to adapt to different target
hardwares would be smoother.
I have not tried this scheme. but think I might do that some time
/Lars
2009/2/27 Jens M Andreasen <jens.andreasen(a)comhem.se>se>:
On Fri, 2009-02-27 at 08:24 -0700, Hans Fugal wrote:
Lars-Erik Helander wrote:
> An interesting/important question though is how many of these 50+
> modules actually contains hw specific adaptions. As an example, for
> audio apps you typically rely on a number of sound ("snd-*") related
> modules of which a fair amount is hardware independent. It is only the
> modules that implement hardware specific adaptions that needs to go
> through the "tedious" identification process.
>
Mmm ... No. Even those modules that I don't know what is has to be
compiled for init (as defined now) eventually to work without errors.
Getting up to init level 2 or 3 is one thing, but then there is no
obvious mapping between the names of "modules not found" and what driver
options should be enabled to get things back to normal.
BTW: I have some 1600 files in modules/drivers! :-D
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev