alsa-lib bloat.

alsa-lib bloat.

[James Courtier-Dutton]

Hi,

On my desktop system, I have this:
/usr/lib/libasound.so.2.0.0
size: 2785380 bytes.

libasound is really too big for what is does.
I was talking to some embedded platform developers recently, and they 
really don't like it at all.

Could something be done about it?
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. I would suggest just using the poll() 
callback method would be needed, as then it is similar to Mac OS X, and 
generally accepted as the best way to talk to a sound device.

I would also like to ask any embedded developers out there who have 
already done this, to post patches back to ALSA so that it saves 
developers time in future.

How about also separating libasound into separate libs, one for PCM, one 
for MIDI, and one for CONTROL that could in turn use a separate "helper 
functions" lib for any common functions. Some embedded applications 
might not need any of the MIDI/sequencer stuff.

Any comments?

James

-------------------------------------------------------------------------
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

Re: alsa-lib bloat.

[Jaroslav Kysela]

On Fri, 8 Dec 2006, James Courtier-Dutton wrote:

> Hi,
> 
> On my desktop system, I have this:
> /usr/lib/libasound.so.2.0.0
> size: 2785380 bytes.

Have you tried to build minimal alsa library?

  --disable-aload         disable reading /dev/aload*
  --disable-mixer     Disable the mixer component
  --disable-pcm       Disable the PCM component
  --disable-rawmidi   Disable the raw MIDI component
  --disable-hwdep     Disable the hwdep component
  --disable-seq       Disable the sequencer component
  --disable-instr     Disable the instrument component
  --disable-alisp     Disable the alisp component

  --with-pcm-plugins=<list>  Build PCM plugins

Note that only hw plugin is important for pcm if applications will do all 
conversions itself.

Just quick test with:

./configure --disable-aload --disable-mixer --disable-rawmidi 
--disable-hwdep --disable-seq --disable-instr --disable-alisp 
--with-pcm-plugins=hw

strip -g --remove-section=.comment --remove-section=.note libasound.so

-rwxr-xr-x  1 perex users 366562 2006-12-09 09:22 libasound.so.2.0.0

It does not look so bad, doesn't?

With mixer stuff:

-rwxr-xr-x   1 perex users 420024 2006-12-09 09:25 libasound.so.2.0.0

> libasound is really too big for what is does.
> I was talking to some embedded platform developers recently, and they 
> really don't like it at all.

The best thing is to discuss what else can be shrinked (removed from 
build). If embedded platform developers stay quiet, we won't care.

For example, all dynamic configuration code can be removed, too.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

-------------------------------------------------------------------------
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

Re: alsa-lib bloat.

[James Courtier-Dutton]

Jaroslav Kysela wrote:
> On Fri, 8 Dec 2006, James Courtier-Dutton wrote:
> 
>> Hi,
>>
>> On my desktop system, I have this:
>> /usr/lib/libasound.so.2.0.0
>> size: 2785380 bytes.
> 
> Have you tried to build minimal alsa library?
> 
>   --disable-aload         disable reading /dev/aload*
>   --disable-mixer     Disable the mixer component
>   --disable-pcm       Disable the PCM component
>   --disable-rawmidi   Disable the raw MIDI component
>   --disable-hwdep     Disable the hwdep component
>   --disable-seq       Disable the sequencer component
>   --disable-instr     Disable the instrument component
>   --disable-alisp     Disable the alisp component
> 
>   --with-pcm-plugins=<list>  Build PCM plugins
> 
> Note that only hw plugin is important for pcm if applications will do all 
> conversions itself.
> 
> Just quick test with:
> 
> ./configure --disable-aload --disable-mixer --disable-rawmidi 
> --disable-hwdep --disable-seq --disable-instr --disable-alisp 
> --with-pcm-plugins=hw
> 
> strip -g --remove-section=.comment --remove-section=.note libasound.so
> 
> -rwxr-xr-x  1 perex users 366562 2006-12-09 09:22 libasound.so.2.0.0
> 
> It does not look so bad, doesn't?
> 
> With mixer stuff:
> 
> -rwxr-xr-x   1 perex users 420024 2006-12-09 09:25 libasound.so.2.0.0
> 
>> libasound is really too big for what is does.
>> I was talking to some embedded platform developers recently, and they 
>> really don't like it at all.
> 
> The best thing is to discuss what else can be shrinked (removed from 
> build). If embedded platform developers stay quiet, we won't care.
> 
> For example, all dynamic configuration code can be removed, too.
> 
> 						Jaroslav
> 

Thanks, that is a good start. I have entered that information into the 
alsa wiki.

https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=AlsaEmbedded



-------------------------------------------------------------------------
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

Re: alsa-lib bloat.

[Liam Girdwood]

Fwiw, I've done some alsa-lib builds (no debug) for ARM with the
following results :-

Default config

-rwxr-xr-x 1 liam liam 948879 Dec  7 16:40 libasound.so.2.0.0


--disable-aload --disable-rawmidi --disable-pcm --disable-hwdep
--disable-seq --disable-instr --disable-alisp --with-pcm-plugins=hw

-rwxr-xr-x 1 liam liam 256320 Dec  9 12:39 libasound.so.2.0.0


--disable-mixer --disable-aload --disable-rawmidi --disable-pcm 
--disable-hwdep --disable-seq --disable-instr --disable-alisp
--with-pcm-plugins=hw

-rwxr-xr-x 1 liam liam 190884 Dec  9 13:08 libasound.so.2.0.0

This final configurations objects can be broken down as follows:-

645 Dec  9 13:59 ./src/compat/.libs/empty.o
2384 Dec  9 13:59 ./src/control/.libs/cards.o
5008 Dec  9 13:59 ./src/control/.libs/control_ext.o
9448 Dec  9 13:59 ./src/control/.libs/control_hw.o
57864 Dec  9 13:59 ./src/control/.libs/control.o
10712 Dec  9 13:59 ./src/control/.libs/control_shm.o
655 Dec  9 13:59 ./src/control/.libs/control_symbols.o
19456 Dec  9 13:59 ./src/control/.libs/hcontrol.o
13144 Dec  9 13:59 ./src/control/.libs/setup.o
3864 Dec  9 13:59 ./src/.libs/async.o
19468 Dec  9 13:59 ./src/.libs/confmisc.o
49540 Dec  9 13:59 ./src/.libs/conf.o
2864 Dec  9 13:59 ./src/.libs/dlmisc.o
3000 Dec  9 13:59 ./src/.libs/error.o
4324 Dec  9 13:59 ./src/.libs/input.o
3608 Dec  9 13:59 ./src/.libs/names.o
4536 Dec  9 13:59 ./src/.libs/output.o
1668 Dec  9 13:59 ./src/.libs/shmarea.o
2768 Dec  9 13:59 ./src/.libs/socket.o
1436 Dec  9 13:59 ./src/.libs/userfile.o

It looks like some further size reduction can probably be achieved by
disabling or reducing features in the conf code for embedded devices as
most only have a single sound card with only one stereo pcm for playback
and capture. 

Liam



-------------------------------------------------------------------------
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

Re: alsa-lib bloat.

[Steve deRosier]

All,

Sorry it's taken me so long to add my 2cp, it's been a bit of a crazy 
few days.

I really don't think libasound should worry about paring down for 
embedded platforms.  Look, ALSA is an _Advanced_ Linux Sound 
Architecture, right?  Yes, it's got a lot of features, code, and 
ultimately power.  There's been complaints over the years of how hard it 
is to use also.  Well, true, but that's often the cost of powerful 
frameworks.

Really, anyone who is using Linux as an "embedded" platform isn't doing 
what I would regard as real embedded work.  Often these sort of 
developers are actually PC (or Linux, or whatever) application 
developers called upon to do embedded work, or are embedded workers 
wanting a common OS and have a board with capabilities that can handle a 
full OS like Linux.  I'm not saying that Linux doesn't have value on 
embedded systems, but really, you're providing a full (even if it is 
custom hardware) nominal computer to the OS in order to get Linux 
running on it, with certain minimum requirements:  This isn't a small 
embedded system with severely limited 8bit processing power, 1MB flash, 
and 256K RAM.

Anyone with severe embedded real time requirements will probably be 
using one of the specially designed embedded OSes or will be using a 
home-grown OS or no OS.  Take a look at the various stats published in 
places like Embedded Systems Programming or compiled by people like Jack 
  Ganssle over the years if you want proof of that assertion.

That said: Linux and ALSA have a great future in the newer 
psudo-embedded systems that are actually tiny industrially packaged PCs. 
  And even in custom boards with enough resources to handle it.  I use 
it and love it.

I do think the power to selectively include or disable feature groups as 
  Jaroslav pointed out is great.  In my experience a few hundred K or 
even a couple of M isn't a killer for most embedded uses that have 
decided to use Linux.

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.

* Do I wish it was sometimes easier to use? Sometimes.
* Do I wish for more features or power? Rarely.  And when I do, I fix it 
where necessary.
* Do I wish the documentation was better?  Sometimes.  But I guess I 
could contribute to that if I was really bothered by it.
* Do I wish the community was better?  Never!  You're all great and 
stand behind the library and answer questions quickly.
* Do I wish it were smaller?  Honestly, I've never noticed the size of 
libasound; I've always had other programs or libraries that are much 
bigger problems.

My vote: by all means make it smaller, and include ways to trim out 
function groupings that a particular application doesn't need.  But, I'd 
rather see the time and effort go into stability, ease of use, speed, 
power, and enhanced compatibility (drivers).

Just the opinion of one actual embedded developer.

Thanks for listening,
- Steve




James Courtier-Dutton wrote:
> Hi,
> 
> On my desktop system, I have this:
> /usr/lib/libasound.so.2.0.0
> size: 2785380 bytes.
> 
> libasound is really too big for what is does.
> I was talking to some embedded platform developers recently, and they 
> really don't like it at all.
> 
> Could something be done about it?
> 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. I would suggest just using the poll() 
> callback method would be needed, as then it is similar to Mac OS X, and 
> generally accepted as the best way to talk to a sound device.
> 
> I would also like to ask any embedded developers out there who have 
> already done this, to post patches back to ALSA so that it saves 
> developers time in future.
> 
> How about also separating libasound into separate libs, one for PCM, one 
> for MIDI, and one for CONTROL that could in turn use a separate "helper 
> functions" lib for any common functions. Some embedded applications 
> might not need any of the MIDI/sequencer stuff.
> 
> Any comments?
> 
> James
> 
> -------------------------------------------------------------------------
> 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
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
> 

-------------------------------------------------------------------------
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

Re: alsa-lib bloat.

[Clemens Ladisch]

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

Re: alsa-lib bloat.

[Takashi Iwai]

At Sat, 9 Dec 2006 09:25:44 +0100 (CET),
Jaroslav Kysela wrote:
> 
> On Fri, 8 Dec 2006, James Courtier-Dutton wrote:
> 
> > Hi,
> > 
> > On my desktop system, I have this:
> > /usr/lib/libasound.so.2.0.0
> > size: 2785380 bytes.
> 
> Have you tried to build minimal alsa library?
> 
>   --disable-aload         disable reading /dev/aload*
>   --disable-mixer     Disable the mixer component
>   --disable-pcm       Disable the PCM component
>   --disable-rawmidi   Disable the raw MIDI component
>   --disable-hwdep     Disable the hwdep component
>   --disable-seq       Disable the sequencer component
>   --disable-instr     Disable the instrument component
>   --disable-alisp     Disable the alisp component
> 
>   --with-pcm-plugins=<list>  Build PCM plugins
> 
> Note that only hw plugin is important for pcm if applications will do all 
> conversions itself.

FWIW, a brief note about partial builds can be found in
alsa-lib/INSTALL file.


Takashi

-------------------------------------------------------------------------
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