Re: ALSA in embedded use (was: Re: future ALSA development)

[Takashi Iwai <tiwai@suse.de>]

At Wed, 1 Oct 2003 12:37:48 +0300 (EEST),
Kai Vehmanen wrote:
> 
> >> - use of more advanced c-lib features such as dynamic loading (dlopen(), 
> > it's possible to create a static library which doesn't need dlopen().
> > but it will eventually link the whole plugin objects statically.
> [...]
> > so, maybe a compromise is to add configure options or something to
> > choose the components (e.g. plugins) to be built in.  this will reduce
> > the size of binary, too.
> 
> Ok, this is good to know. Does this already work now (i.e. when dlopen()
> is not available)? 

no, volunteers wanted :)

> > there are some parts which use glibc's extension (like jump to label
> > address or function-in-function).  but these can be fixed with the
> > standard style, too.  they are mostly optmizations only.
> 
> Hmm, so I guess we'd need someone who actively uses dietlibc (or some 
> other) with ALSA. Otherwise it will be hard to keep alsa-lib 
> clean from glibc-isms. Any volunteers? :)

ah, sorry, the above is a typo.  i wanted to write "gcc".
it should be independent from glibc or dietlibc.


> >> apps to directly communicate with ALSA's kernel interface.
> > mmm, this should be never done.
> > one of the reason to have alsa-lib is to avoid this.
> 
> But the risk is there, see my comments above about libasound size.

for that, we'll need a diet alsa-lib.
this wouldn't be too big, since it's just a wrapper.


Takashi


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