Farstream call: delay on incoming audio

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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!


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Farstream call: delay on incoming audio

Nicolas Dufresne-5
Le jeudi 14 juin 2018 à 16:52 +0100, David Woodhouse a écrit :

> 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.
Can you try and set property "start-time-selection" on liveadder /
audiomixer to (1): first. I think the liveadder shm is not setup
properly and will cause regressions like this.

>
> 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!
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Farstream call: delay on incoming audio

David Woodhouse


On Thu, 2018-06-14 at 13:30 -0400, Nicolas Dufresne wrote:

> > 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, [outbound] audio is working fine.
>
> Can you try and set property "start-time-selection" on liveadder /
> audiomixer to (1): first. I think the liveadder shm is not setup
> properly and will cause regressions like this.
Thanks.

That seems to be making a difference although it's still not entirely
clear that the delay on startup when I'm running with all this
debugging, is the same as the delay on startup with no debugging and if
I leave it for a day. 

I'll start it without the debugging and then see if it's still actually
working tomorrow :)
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Farstream call: delay on incoming audio

David Woodhouse
On Thu, 2018-06-14 at 20:46 +0100, David Woodhouse wrote:

> On Thu, 2018-06-14 at 13:30 -0400, Nicolas Dufresne wrote:
> > > 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 queueX:src threads IIRC) for 30-40 seconds before you
> > > ever hear anything. Meanwhile, [outbound] audio is working fine.
> >
> > Can you try and set property "start-time-selection" on liveadder /
> > audiomixer to (1): first. I think the liveadder shm is not setup
> > properly and will cause regressions like this.
>
> Thanks.
>
> That seems to be making a difference although it's still not entirely
> clear that the delay on startup when I'm running with all this
> debugging, is the same as the delay on startup with no debugging and if
> I leave it for a day. 
>
> I'll start it without the debugging and then see if it's still actually
> working tomorrow :)
Still working on Monday without having to restart Pidgin; I'm fairly
sure that's the first time that's ever happened. I declare it fixed;
thanks again.

https://bitbucket.org/pidgin/main/pull-requests/379
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

smime.p7s (6K) Download Attachment