[GnomeMeeting-devel-list] [BETA6] the "Georgi! I did it!" release

[PUYDT Julien <julien puydt laposte net>]

Hi,

this is a back to BETA move, and for a good reason: the manager code
changed a lot. In fact, it is almost new. With a new API too.

Let's break the news: this manager is not only for video input. It
handles devices of various types; in fact any combination of video
in/out and/or audio in/out...

Currently available plugins:
* v4l: only video in, pure port of the previous RC1 version to the new
scheme;
* avc: only video in, pure port of the previous RC1 version to the new
scheme;
* oss: only audio in&out, pluginization of the current pwlib oss driver.

The fact that a single plugin may handle both audio&video means that if
a same device provides both, and has exclusive access (ie: not two
process can open it at the same time), a single plugin will be able to
reuse the file descriptor or whatever handle is used, to manage both
audio&video. Different managers for audio & video wouldn't have been
able to do so, as it would have meant some way for plugins to share some
sort of device descriptor...

How to patch pwlib:
* plugins.h belongs to $(PWLIBDIR)/include/ptlib/;
* plugins_dlopen.cxx belongs to $(PWLIBDIR)/src/ptlib/unix;
* pwlib.patch should be applied
* move $(PWLIBDIR)/include/ptbuildopts.h.in to
$(PWLIBDIR)/include/ptbuildopts.h.in.in

How to patch openh323:
* apply openh323.patch;

How to patch gnomemeeting:
* apply gm.patch

How to write a plugin, for example an alsa plugin:
* declare a class PSoundChannelAlsa : public PSoundChannel, in a
sound_alsa.h, and make sure to #include <ptlib/plugins.h>;
* implement the PSoundChannelAlsa class, in a sound_alsa.cxx;
* add the following hooks in the .cxx (after the inclusion of
sound_alsa.h, of course):
DECLARE_PLUGIN("ALSA", PDeviceManager:SNDIN | PDeviceManager:SNDOUT);
DECLARE_PLUGIN_SOUNDINPUT(PSoundChannelAlsa);
DECLARE_PLUGIN_SOUNDOUTPUT(PSoundChannelAlsa);
* that's all!
Of course, this howto is a little sketchy, but the point is: you don't
have to worry too much about your driver being a plugin or not, just
write a driver implementation, and the pluginization will come readily!

There will probably be some little change in the next beta (like: SNDIN
-> SoundIn, this type of esthetic stuff), but I think I got the basics
right. There should be no regression from the no-plugin pwlib. I'm not
100% sure the API of the manager is perfect, perhaps I may also add that
"GetDefaultDevice" function for the sound... I don't like it, but
well... Any comment is of course welcome!

TEST! TEST! TEST! REPORT! REPORT! REPORT!

Snark

PS: Georgi, here is a rough plan of how we could get audio&video in avc:
* write an AVCSND plugin, that will handle sound (it can be separate
from video, since you told me concurrent access is possible);
* test it;
* merge it with the AVC plugin as an AVC plugin, that will declare
itself as handling both video in & sound in;
* test it;
* try to share the decompression&handle to see if it makes a
performance/load difference;
* test it;

I don't know how much of it I can do... since I'm focusing more on the
manager than the plugins... so perhaps the "we" will only be you + some
random advice ;-)