Audio src blocked before session set up

[David Woodhouse]

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?

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?
-------------- 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/f78acd8c/attachment-0001.bin>