FsAppTransmitter / dummy call in nullprpl

[Jakub Adam]

Hi David,

after commenting out

  "wait-for-connection", FALSE,

in g_object_set() of the file sink (which is a property GstFileSink doesn't have)
Pidgin started saving raw audio into /tmp/pidgin.s16 and I was also able to import
the file to Audacity and play it back correctly.

It seems when g_object_set() encounters a property unknown to the given GObject,
it exists immediately and leaves the properties that follow unchanged.
When I reordered the call so that "wait-for-connection" came last, all worked well:

  g_object_set (elem,
      "location", "/tmp/pidgin.s16",
      "async", FALSE,
      "sync" , FALSE,
      "wait-for-connection", FALSE,
      NULL);

From the values you are setting, "async" looks like the important one which must
be FALSE for the Pidgin pipeline to work.

Regards,

Jakub

On 6.11.2017 09:46, David Woodhouse wrote:
> On Thu, 2017-11-02 at 15:23 +0000, David Woodhouse wrote:
>> 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.
> 
> I pushed the above-mentioned testing hack to 
> https://bitbucket.org/dwmw2/pidgin/commits/branch/dummyconf
> 
> Although you're supposed to be able to build the nullprpl on its own,
> Pidgin 2.12.0 will crash when used with anything but fsrtpconference,
> because it expects the FsCandidate to have a 'cname' property:
> https://bitbucket.org/dwmw2/pidgin/commits/63c0b6b6b
> 
> The above branch is based on the latest pidgin-2.x.y which includes
> that fix.
> 
> 
> 
> _______________________________________________
> Farstream-devel mailing list
> Farstream-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/farstream-devel
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 516 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/farstream-devel/attachments/20171106/0878925c/attachment.sig>