Re: alsa-lib bloat.

["Clemens Ladisch" <cladisch@fastmail.net>]

Steve deRosier wrote:
> [...]
> For me it boils down to this: libasound was designed for and is intended 
> for advanced usage by people that were unsatisfied with the capabilities 
> and performance of the more simple interfaces provided with Linux a few 
> years ago.  It is powerful and exactly what I need for our advanced
> usage.

But one problem is that libasound is the only interface, especially
since OSS was deprecated.  The plugin mechanism and the configuration
parser are used by all applications, even if they wouldn't be necessary
on a particular system.

> James Courtier-Dutton wrote:
> > I was thinking that we could really cut down the API to a very limited 
> > subset of the current api, and place #ifdef in the source code, so that 
> > developers could build alsa-lib for embedded systems using just this 
> > subset of the current api.

Using a subset would make it incompatible with the 'real' API.

The hundreds of snd_xxx_get/set_yyy() functions are just wrappers around
a "xxx->yyy = val" or "return xxx->yyy".  If we assume that only "hw"
devices are used, most API calls boil down to a thin wrapper around an
ioctl() call.  So, in a non-dynamic library, all those functions could
be made inline or a macro.

However, this would require a complete reimplementation of the
'embedded' libasound.


Regards,
Clemens

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV