> 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 = "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.
On Tue, Jun 27, 2017 at 11:12 AM, Tanu Kaskinen <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. 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
>
--
Prof.° Wellington Wallace Miguel Melo
CEFET/RJ Uned Nova Iguaçu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20170627/f0c2dd83/attachment.html>
