[pulseaudio-discuss] lots of [null-sink] memblock.c: Pool full

[Tanu Kaskinen]

On Sun, 2017-06-25 at 16:14 -0300, wellington wallace wrote:
> Hi,
> 
> Today I noticed I have lots of these messages in Pulseaudio debug output:
> 
> jun 25 15:44:11 wwmm pulseaudio[1148]: D: [alsa-sink-ALC887-VD Analog]
> ratelimit.c: 1685 events suppressed
> jun 25 15:44:11 wwmm pulseaudio[1148]: D: [alsa-sink-ALC887-VD Analog]
> memblock.c: Pool full
> jun 25 15:44:11 wwmm pulseaudio[1148]: D: [null-sink] memblock.c: Pool full
> 
> They happen when I am using my application
> https://github.com/wwmm/pulseeffects. In PulseEffects I load a null sink
> and then launch a gstreamer pipeline where the pulsesrc plugin records from
> the null sink monitor device. I wonder if I am doing something wrong. It
> seems to me that these messages should not be there when everything is
> alright. Is that so?

If the mempool is full, then all memblocks from the pool are in use,
and pulseaudio has to use malloc() to allocate new blocks. Either the
pool is just too small for the use case, or something is leaking (i.e.
not releasing) memblocks.

Applications don't interface with the mempool directly, but if a
recording application doesn't consume the audio that the server sends,
then memblocks will be queued in the stream buffer (usually up to 4MB).
This could cause shortage in the mempool, especially if the configured
latency is low, because in that case the blocks are reserved at a
higher rate. I don't know how else this could be the application's
fault.

You can check with "pactl list source-outputs" how big the "buffer
latency" of your recording stream is. If it's small, then I don't think
the problem is in your application.

> As someone new to the development of Pulseaudio applications I would also
> like to ask what is the proper when to finish an application that is using
> Pulseaudio. The documentation tells to disconnect from the context and I am
> already doing that. Is there something else I should do when closing the
> application? Like calling unref on context?

Yes, you need to call unref on all objects that your application is
holding a reference to, and that includes the context object.

-- 
Tanu

https://www.patreon.com/tanuk