FsAppTransmitter / dummy call in nullprpl

[David Woodhouse]

I'm working on a Pidgin protocol plugin (prpl). It's under LGPL but I
haven't completed the internal politics which will allow me to release
it, although I intend to as soon as I can.

Some weeks ago, I reached the point where I can send and receive audio
data. It's multiplexed along with all the other protocol data within a
websocket, and I have a hack which hooks it up directly via
gstappsrc/gstappsink in a pipeline with autoaudiosink/autoaudiosrc
respectively.

The hard part is actually getting it working as a "proper" call through
farstream and Pidgin. Here's what I've done so far:

I've taken a copy of FsShmTransmitter and turned it into a
FsAppTransmitter, which will have gstappsrc/gstappsink for each
candidate (or will only support one candidate, since more than one
seems pointless. But I haven't changed that yet). Since there is no
"client-connected" signal, I call the 'connected_cb' directly to set
the stream into FS_STREAM_STATE_READY.

Right now, I'm actually using audiotestsrc and filesink, because I'm
*only* testing that I can set up the pipelines and manage the
farstream /gstreamer side correctly. I'll worry about using *real*
gstappsrc/gstappsink once I have this working.

I have a patch to the nullprpl which lets me reproduce this via a
'Dummy call' menu option in the account menu, at 
http://david.woodhou.se/0001-Dummy-conference-hack-to-nullprpl.patch

In addition to the FsAppTransmitter as described above (and with
'create-local-candidates' defaulting to TRUE until I rip that code out
too), I've just got this simple invocation in the null prpl:

+  PurpleMediaManager *mgr = purple_media_manager_get();
+  PurpleMedia *media = purple_media_manager_create_media(mgr,
+							 acct,
+							 "fsrawconference",
+							 name,
+							 TRUE);
+  GList *cands = g_list_append (NULL,
+				purple_media_candidate_new(NULL, 1,
+				   PURPLE_MEDIA_CANDIDATE_TYPE_HOST,
+				   PURPLE_MEDIA_NETWORK_PROTOCOL_UDP,
+				   "/tmp/src1", 0));
+
+  GList *codecs = g_list_append(NULL,
+				purple_media_codec_new(1, "audio/x-raw, format=(string)S16LE, layout=(string)interleaved, rate=(int)44100, channels=(int)1", PURPLE_MEDIA_AUDIO, 0));
+
+  purple_media_add_stream(media, sess, name,
+			  PURPLE_MEDIA_AUDIO, TRUE,
+			  "app", 0, NULL);
+
+  purple_media_add_remote_candidates(media, sess, name, cands);
+  purple_media_set_send_codec(media, sess, codecs->data);
+  purple_media_set_remote_codecs(media, sess, name, codecs);
+  purple_media_stream_info(media, PURPLE_MEDIA_INFO_ACCEPT, sess, name, FALSE);

I also hacked libpurple to dump the whole pipeline to a dot file when I
press a DTMF key in the call dialog, since adding a call immediately
after the above code didn't seem to show a full pipeline — it completes
asynchronously, later.

Receiving audio from the audiotestsrc seems to work fine. I get the
generated tone through my speakers. Hooking it up to an actual
gstappsrc in my own prpl seems easy enough as I have that coded
elsewhere.

The problem is the other direction. I was hoping that data from the
microphone would end up in the file written by my filesink, but the
file is empty.

Looking in the dot file http://david.woodhou.se/conference%20graph.dot
I see that everything in fsappbin1 is paused (=). What am I doing
wrong?

Full output with GST_DEBUG=6 at
http://david.woodhou.se/nullprpl-dummy-call.txt

Any further clues would be very much appreciated! Thanks Jakub for all
the pointers so far.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4938 bytes
Desc: not available
URL: <https://pidgin.im/pipermail/devel/attachments/20171102/ff4677d1/attachment.bin>