[pulseaudio-discuss] Hard-coded allocation of 64 MB of memory upfront too big in some scenarios

[Lennart Poettering]

On Tue, 26.08.08 15:26, CJ van den Berg (cj at vdbonline.com) wrote:

> 
> On Tue, Aug 26, 2008 at 01:10:13PM +0000, rdiezmail-pulseaudio at yahoo.de wrote:
> > I'm compiling the client library for an embedded PowerPC target
> > without shared memory or the like. In fact, the device has much less
> > memory than a standard PC.
> > 
> > In this scenario, PA_MEMPOOL_SLOT_SIZE is set to a rather big value in pulsecore/memblock.c :
> > 
> > #define PA_MEMPOOL_SLOT_SIZE (64*1024)
> > 
> > That causes allocation of 64 MB at once later on, before establishing
> > any audio connections to the server. If you're using the client
> > library's asynchronous interface to play a simple sound say from a
> > file, you don't need that much memory, do you? How much should I go
> > for?
> 
> The memory is *not* allocated, it is only mapped. No actual memory will
> be used until a client connects (via shared memory), and even then, it's
> only 64K per client.

64K per client? That's not true. 

Every client and the daemon allocate one 64MB pool. Every time the
daemon wants to pass data to a client, or a client wants to send data
to the daemon one memory block is allocated from the respective
pool. Such a block will have a size of 64K, of which probably only
the first part is used. However, each client and the daemon will
usually have allocated more than a single block at the same time.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4