Farstream call: delay on incoming audio

[David Woodhouse]

Using the Amazon Chime plugin for Pidgin
(https://github.com/awslabs/pidgin-chime) I am seeing strange behaviour
with audio calls.

The longer Pidgin has been running, the longer it takes before I
receive incoming audio, after joining a call. There's normally a
"bleep" when you join a call. Unless you've *recently* started Pidgin,
you don't hear that. It gets to the point where Pidgin eats CPU (in the
liveadderX:src and queue:src threads IIRC) for 30-40 seconds before you
ever hear anything. Meanwhile, inbound audio is working fine.

Here's the pipeline graph of a sample call:
http://david.woodhou.se/chimegraph-20180614.svg

Output of the following command:
$ CHIME_DEBUG=1 GST_DEBUG_DUMP_DOT_DIR=/tmp GST_DEBUG=5,audiomixer:9,GST_SCHEDULING:9,appsrc:9,rtpjitterbuffer:9  /opt/pidgin2/bin/pidgin -d

... is at http://david.woodhou.se/chimelog-20180614.txt

I join the call at around 00:00:27 and start receiving audio frames
(which are fed into the appsrc):

Audio RX seq 1736 ts 131819330

But I don't actually hear anything until a couple of seconds later. I
think this line is about the time I start hearing anything in my
headset:

0:00:29.904593304 17809 0x7f440400b1e0 DEBUG          audiobasesink gstaudiobasesink.c:2155:gst_audio_base_sink_render:<pulsesink0> rendering at 5434 480/480

Prior to that, pulsesink seems to be dropping frames.

Of course, I'm not sure if what I'm looking at here is the same thing
I've seen without the debugging. This one could just be an aspect of
"debug makes it slow".... any clues on how to work it out would be very
much appreciated!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5213 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/farstream-devel/attachments/20180614/48730c8a/attachment.bin>