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

[wellington wallace]

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?

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?

Best regards,

Wellington

[Tanu Kaskinen]

Post by wellington wallace
Hi,
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.

Post by wellington wallace
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.

[wellington wallace]

Post by Tanu Kaskinen
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.

Hi, thank you for your answer. Buffer latency and source latency have a
value of 0 usec:

Source Output #2
Driver: protocol-native.c
Owner Module: 12
Client: 12
Source: 2
Sample Specification: float32le 2ch 44100Hz
Channel Map: front-left,front-right
Format: pcm, format.sample_format = "\"float32le\"" format.rate = "44100"
format.channels = "2" format.channel_map = "\"front-left,front-right\""
Corked: no
Mute: no
Volume: front-left: 65536 / 100% / 0,00 dB, front-right: 65536 / 100% /
0,00 dB
balance 0,00
Buffer Latency: 0 usec
Source Latency: 0 usec
Resample method: n/a
Properties:
media.name = "Record Stream"
application.name = "PulseEffects"
native-protocol.peer = "UNIX socket client"
native-protocol.version = "32"
media.role = "production"
application.icon_name = "pulseeffects"
application.process.id = "1797"
application.process.user = "wallace"
application.process.host = "wwmm"
application.process.binary = "python3.6"
application.language = "en_US.UTF-8"
window.x11.display = ":1"
application.process.machine_id = "767c0755fd35486daf42d8e1a6d41540"
application.process.session_id = "c3"
module-stream-restore.id = "source-output-by-media-role:production"

I wonder if this problem could be related to the alsa driver. This ALC887-VD
sound card is in a ryzen motherboard (asus prime B350m-a). As this is a new
hardware maybe something is not right at the driver level. I am using
kernel 4.11.6 and Pulseaudio 10 in Arch Linux. I have been suffering with
random cracklings that come and go after shutdown/poweron also at random
(tsched=0 does not help). When they happen I can listen to them even if
using speaker-test to play a sine wave directly to an alsa device. So it
does not seems that Pulseaudio is the one responsible for this crackling.
But I do not know how to pinpoint the exact cause of this problem.

Post by Tanu Kaskinen

Post by wellington wallace
Hi,
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

Post by wellington wallace
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

Post by wellington wallace
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.

Post by wellington wallace
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

Post by wellington wallace
Pulseaudio. The documentation tells to disconnect from the context and I

am

Post by wellington wallace
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

...

[Georg Chini]

Post by wellington wallace

Post by Tanu Kaskinen
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.

Hi, thank you for your answer. Buffer latency and source latency have
Source Output #2
Driver: protocol-native.c
Owner Module: 12
Client: 12
Source: 2
Sample Specification: float32le 2ch 44100Hz
Channel Map: front-left,front-right
Format: pcm, format.sample_format = "\"float32le\"" format.rate =
"44100" format.channels = "2" format.channel_map =
"\"front-left,front-right\""
Corked: no
Mute: no
Volume: front-left: 65536 / 100% / 0,00 dB, front-right: 65536 /
100% / 0,00 dB
balance 0,00
Buffer Latency: 0 usec
Source Latency: 0 usec
Resample method: n/a
media.name <http://media.name> = "Record Stream"
application.name <http://application.name> = "PulseEffects"
native-protocol.peer = "UNIX socket client"
native-protocol.version = "32"
media.role = "production"
application.icon_name = "pulseeffects"
application.process.id <http://application.process.id> = "1797"
application.process.user = "wallace"
application.process.host = "wwmm"
application.process.binary = "python3.6"
application.language = "en_US.UTF-8"
window.x11.display = ":1"
application.process.machine_id = "767c0755fd35486daf42d8e1a6d41540"
application.process.session_id = "c3"
module-stream-restore.id <http://module-stream-restore.id> =
"source-output-by-media-role:production"
I wonder if this problem could be related to the alsa driver. This
ALC887-VD sound card is in a ryzen motherboard (asus prime B350m-a).
As this is a new hardware maybe something is not right at the driver
level. I am using kernel 4.11.6 and Pulseaudio 10 in Arch Linux. I
have been suffering with random cracklings that come and go after
shutdown/poweron also at random (tsched=0 does not help). When they
happen I can listen to them even if using speaker-test to play a sine
wave directly to an alsa device. So it does not seems that Pulseaudio
is the one responsible for this crackling. But I do not know how to
pinpoint the exact cause of this problem.

Post by Tanu Kaskinen
Hi,
Today I noticed I have lots of these messages in Pulseaudio
jun 25 15:44:11 wwmm pulseaudio[1148]: D: [alsa-sink-ALC887-VD

Analog]

Post by Tanu Kaskinen
ratelimit.c: 1685 events suppressed
jun 25 15:44:11 wwmm pulseaudio[1148]: D: [alsa-sink-ALC887-VD

Analog]

Post by Tanu Kaskinen
memblock.c: Pool full
jun 25 15:44:11 wwmm pulseaudio[1148]: D: [null-sink]

memblock.c: Pool full

Post by Tanu Kaskinen
They happen when I am using my application
https://github.com/wwmm/pulseeffects

<https://github.com/wwmm/pulseeffects>. In PulseEffects I load a
null sink

Post by Tanu Kaskinen
and then launch a gstreamer pipeline where the pulsesrc plugin

records from

Post by Tanu Kaskinen
the null sink monitor device. I wonder if I am doing something

wrong. It

Post by Tanu Kaskinen
seems to me that these messages should not be there when

everything is

Post by Tanu Kaskinen
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.
--
Tanu
https://www.patreon.com/tanuk
--
Prof.° Wellington Wallace Miguel Melo
CEFET/RJ Uned Nova Iguaçu

...

For what it's worth I 'm seeing the same messages when I run
module-loopback at low latencies.
It does not seem to affect the audio though.