Past : itched by gnomemeeting

Years ago, I was discovering a wonderful program : gnomemeeting. It already made it possible to make calls with both audio and video (that was years ago and some projects still struggle to do things half as good!). And I happened to have two video devices available : a USB webcam, and a IEEE1394/FireWire/iLink/whatever-the-vendor-felt-would-sell-more DV camcoder.

And this is where things got tricky. Pwlib, the library which gnomemeeting used to handle devices had a PVideoInputDevice class (it’s C++), and several implementations of it — moreover it had implementations for both my devices! That was really a feat :

1. at the time the kernel had very, very poor device support for video — but both had a driver
2. someone else already added support to pwlib!

The big issue was that switching from one device to another required recompiling the whole of pwlib with a different option. Ouch.

So here was the itch. And this one turned me from a libre software user to a libre software developper : I decided I would make it possible to switch them at runtime — which mostly meant changing the structure from a #ifdef tree to a nice class tree, with dynamic loading and a simple listing ability. Of course, C++ made it a pain because I had to track each and every method to add the “virtual” keyword all over, but I’ll rant about C++ another day (and perhaps say also a good thing or two about it — three if Dodji hits me hard enough).

Present : pretty good, but still

This initial contribution prompted other contributions, which triggered other contributions, which… This is why ekiga (gnomemeeting’s new name) has a very good device support these days, through the use of plugins, which exist for various platforms (GNU, *BSD, win32, …).

But those plugins themselves are all based directly on platform-specific API. We have ALSA, OSS, V4L, V4L2, AVC and DC, just to name those which work on GNU/Linux based systems. Whenever some incompatibility happens, we have to fix it ourselves for ourselves : it’s all about us.

And this is why I’m not satisfied. I would rather see pwlib have support for a single portable audio and/or video framework, which would be shared by as many projects as possible. That would have huge advantages : first the user interface would be simpler (we currently make the user choose among a list of badly-named managers before they choose the device) and then both problems and solutions would be shared on many shoulders.

Notice that this isn’t pwlib bashing : the current organisation made sense, since there was no such framework at that time. Things are different now : there are different choices — and possibly we can take several of them at first before picking the most suitable.

Future : choices

Using portaudio

Portaudio is a nice portable audio framework — we are almost using it already. The positive part of ‘almost’ is that we do have a plugin. The negative part of ‘almost’ is that it doesn’t work correctly yet. Let me admit that I’m a little stuck. 🙂

Using GStreamer

This one I don’t think I need to link to here : all must have heard about it already. This is a wonderful framework. Does audio and video. Will probably do what ekiga needs network-wise at some point in the future. Unfortunately, it is wonderful as long as you manage all of your data with it — things get more difficult if you just want to use it partly.

Let me get into more details here : my original plan was to write device plugins for pwlib, then as time go by use it more and more up the data streams until it’s everywhere. Yes, that framework makes me giggle, so I would like it used more.

But the problem I hit is that to do that, you need to do some plumbering between the GStreamer framework and pwlib’s own stream framework. And this isn’t easy. I do have some experimental code, both for audio and video, but they’re hackish ; the real solution would be to fix this bug, which is precisely about having bridge elements to allow plumbering (not just to pwlib, but to whatever other framework you may want to throw at it).

Of course, I didn’t just report issues, I also tried to report with minimal examples showing the issues, and even some patches. Eh, the goal is to share after all. Both code and problems!

Conclusion

So as you can see, contributing to device support is a very good way to start hacking on a project : if anyone wants to lend a hand — please do!

And don’t think you’ll always be stuck with devices : it’s just that you’ll always come back to them 😉