Audio src blocked before session set up

[David Woodhouse]

On Thu, 2018-04-19 at 07:43 +0000, Joakim Tjernlund wrote:
> On Thu, 2018-04-19 at 08:33 +0100, David Woodhouse wrote:
> > On Thu, 2018-04-19 at 07:04 +0000, Joakim Tjernlund wrote:
> > > On Wed, 2018-04-18 at 22:18 +0100, David Woodhouse wrote:
> > > > I've suddenly started experiencing a problem where my outbound audio in
> > > > Pidgin is missing — Farstream never seems to send any audio, and I
> > > > don't even get the farstream-send-codec-changed signal.
> > > > 
> > > > It's sporadic, and relatively hard to reproduce. And of course the more
> > > > I turn up the GST_DEBUG debugging, the harder it gets.
> > > > 
> > > > It looks like the problem occurs when pulsesrc gets blocked:
> > > 
> > > I have somewhat similar issue in sipe, but input instead. If I change to ALSA and
> > > do a test call, then the microphone locks up just as the call connects.
> > > If I recall correctly, USB headsets are needed as well. 
> > > Using Pulse it usually works.
> > Yeah, that's the same direction — my microphone locks up. I'm also
> > using a USB headset; perhaps that just affects the latency between
> > Pidgin setting it to PLAYING, and the first sample arriving?
>
> Yes, I think so. My Lync server is in USA and I in Sweden, quite much latency there.
> Adding USB latency on top kills my microfone.

I don't *think* the network latency is relevant here; this just about
how long it takes for the microphone to send its first sample, during
the purple_media_add_stream()...purple_media_add_remote_candidates()...
purple_media_set_remote_codecs()... code flow.

Although if some of the SDP/ICE negotiation is done over the wire in
that time for you, perhaps it does make a difference? 

And I only really started seeing it this week, which is the first time
I've been using my code "in anger" for real calls since I implemented
the DTLS transport. So yeah, maybe the timing of the first incoming
packet is also relevant somehow; I'm not sure.
 
> > 
> > 
> > If the first sample arrives *before* the rest of the call setup, it
> > seems to be OK. It's failing if the sample arrives *during* the call
> > setup, especially (I think) before _send_src_pad_blocked_callback() is
> > registered by fs_rtp_session_verify_send_codec_bin_locked().
> > 
> > Should fs_rtp_session_verify_send_codec_bin_locked() actually be
> > checking if the pad was *already* blocked, and setting up the codecbin
> > immediately if so?
>
> I cannot say how/where to fix but I will try any patch you throw at me and/or
> provide logs(just tell me what env. variables to set please :)

Let's start by checking it's the same issue. Does it also occur only
for some calls? 

Let's look for that 'Task going to paused' message on your microphone
src element, that I highlighted in my first email. Try something like
this and compare a working call to a silent one:

	GST_DEBUG=3,basesrc:7,task:7 pidgin -d

Annoyingly, I can't reproduce it at all today.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5213 bytes
Desc: not available
URL: <https://pidgin.im/pipermail/devel/attachments/20180419/0e4ac90b/attachment.bin>