[pulseaudio-discuss] shm size

[Lennart Poettering]

On Tue, 30.09.08 09:54, Nick Thompson (rextanka at comcast.net) wrote:

> Heya,
>
> OK that was badly phrased.  It's not a leak, it does not grow, and is the 
> same size each time pulseaudio is launched.
>
> I presume the shm is created with the size of memory that is preallocated.  
> Here's what would be useful to know.

Yes.

> What is the basis for the decision to preallocate that amount?

I had something of 4MB a few version ago. That turned out not be
enough for machines with lots of local sound card. In the end the size
doesn't matter too much. It's just an upper limit. So I increased by a
factor of 16.

> If the number of streams expected to be active at any one time is limited, 
> could the pre-allocation reasonably be reduced?

Not right now. Changing the size of the mapping would require
rearranging of current allocated memory blocks which is problematic in
a real-time environment where you shouldn't just stop the memory
manager for a certain time completely. 

Also, why should it be reduced? What's the point?

> Is the preallocation an amount per expected stream (presumably based on the 
> buffer sizes usually being requested) plus some overhead.  Any idea what 
> these values are?

It's 64M for each PA client and each PA server. But again, The 64M
aren't actually used in memory. It's just some upper limited. Only
when the memory is used it is actually backed by RAM. Check "du". 

> Or if these values are unknown, should I just tool around and keep reducing 
> the amount pre-allocated until the audio stack fails?

Why would you want to do that?

The size of this POSIX SHM seg is only an allocation of address space,
not actual memory. It really shouldn't matter what size we pick.

Lennart

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