Re: future ALSA development

[Takashi Iwai <tiwai@suse.de>]

At Thu, 3 Jul 2003 16:39:36 +0300 (EEST),
Kai Vehmanen wrote:
> 
> Ok, this is a bit late, but hopefully not too late. :)
> 
> On Tue, 24 Jun 2003, Joern Nettingsmeier wrote:
> >>> other people might propose XML.  then it becomes to a question whether
> >> I think that XML is too overkill for our purposes.
> > otoh, the embedded guys will probably not like it, but then memory is 
> > becoming cheaper by the minute, and its additional size will be a moot 
> > point in the very near future.
> 
> This is a dangerous argument. While it's that true memory and cpu power
> are becoming cheaper and cheaper all the time, minimizing resource usage
> is still as important as ever. With big volume products, small things make
> a big difference in the overall picture (i.e. which products survive in
> the market). Saving an extra 100kB can make a huge difference if it allows
> you to use a smaller flash chip on your device.
> 
> This doesn't mean ALSA should not take advantage of any additional
> libraries, but these additions should not create new dependendencies to
> the core system. In other words you should be able to build a compact
> version of ALSA user-space libs and tools, and one that is cross-compiler
> friendly. Otherwise people will be tempted to use OSS or write their own
> drivers.
> 
> Already alsa-lib has some features that are not so good from embedded 
> perspective:
> 
> - not a small lib; with default settings around 0.5MB; this 
>   is an extra 0.5MB compared to just using OSS where there is no lib

that's true.

> - use of more advanced c-lib features such as dynamic loading (dlopen(), 
>   etc); these can cause problems if you try to use libasound with other
>   c-libs than glibc

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.

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.


> ... but, but, of course libasound also provides lots of great
> functionality, so it's still a good alternative. And also, app developers
> can always manually scale down the libasound build,

yep

> or even write their
> 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.


Takashi


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01