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

[Georg Chini]

On 27.06.2017 16:47, wellington wallace wrote:
> >Tanu wrote:
> > 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 <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.
>
>
> On Tue, Jun 27, 2017 at 11:12 AM, Tanu Kaskinen <tanuk at iki.fi 
> <mailto:tanuk at iki.fi>> wrote:
>
>     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
>     <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.
>
>     --
>     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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20170703/ffdc3399/attachment.html>