On Mon, 2017-10-09 at 19:52 +1030, Steven Wawryk wrote:
> On 08/10/17 03:30, Tanu Kaskinen wrote:
> > On Tue, 2017-09-26 at 19:27 +0930, Steven Wawryk wrote:
> > > We've upgraded the I/O board (the platform with the module-loopback) to
> > > use PulseAudio 11.1, but seem to be getting the same result. Also tried
> > > adding the latency parameters that are used by module-loopback,
> > > module-alsa-sink, module-alsa-source and module-rtp-recv. We've even
> > > observed latencies of several minutes.
> > >
> > > Using pactl list sinks/sources/sink-inputs/source-outputs, the biggest
> > > latencies listed are in the tens of thousands of usec, so there doesn't
> > > seem to anything that accounts for it. This is true on the workstation
> > > too. I can't work out where the big latency is added.
> > >
> > > There are some odd messages in the log (with -v). I've attached the
> > > compressed, filtered log ("grep pulse"):
> > >
> > > * module-loopback seems to be "dropping" a lot of audio
> > > ("module-loopback.c: Dropping 920177108 usec of audio from queue") and
> > > "adding" a lot of silence ("module-loopback.c: Adding 920174784 usec of
> > > silence to queue") to the "queue".
> >
> > If module-loopback is adding 920 seconds of silence to its buffer, that
> > seems like the likely reason for the extremely high latencies. The code
> > that calculates this number seems to be getting garbage from some
> > input. I suggest adding more logging to the module-loopback code to
> > find the garbage source.
>
> I've attached a compressed, filtered log with -vvvv supplied to
> PulseAudio. There's nothing that jumps out at me to help find the
> source of the garbage.
By "adding more logging to the module-loopback code" I meant editing
the source code in src/modules/module-loopback.c. The interesting log
message is this:
pa_log_info("Adding %lu usec of silence to queue", pa_bytes_to_usec(buffer_correction, &u->sink_input->sample_spec));
buffer_correction appears to be garbage, but it's not known why. You
can add more log messages that show each step of the buffer_correction
calculation. If you trace the calculations back far enough, you'll
hopefully find the root cause of the abnormally large buffer_correction
value.
--
Tanu
https://www.patreon.com/tanuk
