The Wayback Machine - https://web.archive.org/web/20170628222046/http://www.advogato.org/person/phkhal/diary.html?start=2

Older blog entries for phkhal (starting at number 2)

19 Mar 2006 (updated 19 Mar 2006 at 23:35 UTC) »

Lately I have been working on Farsight and GTalk. Here are the different components I needed to get it working.

LibjingleP2P I wanted to get gtalk support in there using libjingle. Unfortunatly libjingle came fully loaded with all sorts of stuff I did not need (media engine, signaling). Basically I only wanted the P2P stuff (outgoing STUN, ICE/inline STUN, TURN). So I hacked open libjingle and came up with a p2p only libjingle that can be found here.

icesrc/icesink Next step was getting that P2P Socket to interface with gstreamer. Therefore I wrote 2 elements, icesrc and icesink that can be found here. They connect to those C++ signals on libjingle's P2PSocket and receive/send packets through that socket. Hopefully these elements will be used by jingle upstream to use gstreamer as the default media engine one day instead of linphone. :P

Telepathy gabble I had my own signaling for GTalk thanks to Telepathy's Gabble XMPP connection manager.

voip-engine Next step was to hook up the Signaling from Gabble with Farsight through the d-bus interface and the voip engine. The voip-engine uses the Farsight RTP plugin that takes care of setting up the gstreamer pipeline as well as creating the required libjinglep2p instances.

In the end it actually all worked. The interesting thing is that most of the components mentioned above can be used separately. For example, the modified libjingle can be used to establish any P2P connection for any purpose with a very high sucess rate of traversing NATs (specially if you setup/use a TURN server).

Today I remembered I had a blog. Last entry was exactly 3 months ago! I'm due.

GStreamer Profiler

Last couple of days I have been working on a simple profiler for GStreamer. Basically I wanted to see how much time each packet was spending inside the pipeline and inside the different elements. Specifically for RTP that requires good latency. I wanted something non-intrusive that didn't require any changes to the existing elements, and I wanted something fast so it wouldn't make the collected data useless. It also needed to be thread-safe since elements can run in different threads. After some discussion on irc I came up with a simple profiler that works. Basically it allocates a memory space and uses an atomic pointer to insert structs into that memory space. The structs have some data such as the element name, the buffer size, the time of the log, etc. As for doing the actual logging, I simply override the gst_pad_push() and gst_pad_chain() functions using LD_PRELOAD magic. This will log most buffers when they enter/leave each element in the pipeline. For the moment it simply puts the collected data in a log file, but in the future I want to write some processing code that give me easier to read data.

Here is a screenshot. The yellow and red colors represent the 2 different threads (one for receiving and one for sending). The sinks/sources on each thread are also colored. Other than giving timing information it also allows me to more easily see the flow of packets happening in the pipeline.

Ok. So I have eventually started a blog. I guess it was inevitable :) Today, I also finished my last exam of my Bachelor of Computer Engineering. This means, I now have the rest of my life to develop open source software.

First step, Farsight. I'll be working more on Farsight from now on, including all RTP Gstreamer work. The RTP in GStreamer is coming along nicely, but still alot of work needs to be done. Fortunatly, all this work is mostly enhancements to a base that I hope is solid. Soon we will have drift control in there, as well as support for multiple codecs per stream. Later we will work on mulitparticipant support and alot of other goodies :)

Ok, time to go order that X40 !

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!