[pulseaudio-discuss] Memory management and other issues in the client library

[rdiezmail-pulseaudio at yahoo.de]

> PA is not designed for unpaged, shm-less MMU-less
> devices. (Didn't we have this topic on the ML already a
> week ago?
> [...]
> And don't forget. PA is no database software. It's
> just an audio daemon. 

Again, I must disagree on that point. My embedded PowerPC system runs Linux. It has a MMU, and it's being actively used. You can even turn on virtual memory swapping on an NFS share (not that you would want to in an embedded device).

Hey, my embedded device hasn't even got a sound card! And that's fine, because PA is not just an audio daemon. It's also a client library to connect to one.

In fact, I guess most users of the PA source code would only be interested in the client library. That is, assuming PA manages to gain acceptance in the audio app community. App developers have little control of which PA daemon version their distribution of choice bundles by default. But they will be using the latest version of the client library. That's why I think it should be easier for developers to separately download and build the client library. I don't want to install libsamplerate and the rest just to get the latest libpulse version. One would expect to see a separate forum just for client library programming issues.

But back to the memory management point: the only thing my embedded Linux does not have is shared memory support turned on in the kernel. And that's fine. You don't need shared memory in the client library if you want to connect to the main audio server via TCP/IP. In fact, the client library should use shared memory only to speak to a local daemon, if available. For TCP/IP connections, it shouldn't touch it.

Furthermore, the client library should not implement its own memory management. It should give the application the choice of which malloc/free to use, like zlib. It should not implement a memory pool (imagine if every library implemented its own memory management once again). It should return all memory as soon as possible to the C library, so that the released memory becomes available to the host application. It should not allocate some fixed 64 MB of memory upfront, just because this figure has been seen to improve performance on the daemon side.

If I want to write a small application which just plays a silly sound once in a while, I should be able to compile the client library down to something lean and mean, even if my current host PC supports every conceivable memory and network technology.

If the client library needs special memory features for real-time (like "do not swap out" flags), it should pass some flag to the application-provided malloc routine. That's assuming you still have any real-time hopes when you connect via TCP/IP.

The server daemon can do everything differently and support all possible technologies on a fully-featured PC, that's not important for most applications.


__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. 
http://mail.yahoo.com