Audio src blocked before session set up

[Joakim Tjernlund]

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.

> 
> 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 :)

 Jocke