Re: [GnomeMeeting-devel-list] [BETA7] the "I'm in a real hurry" release

[PUYDT Julien <julien puydt laposte net>]

Le mar 12/08/2003 à 11:35, Damien Sandras a écrit :
> That leads us to think about the way GM should use the plugins.
> 
> For video, that is easy: all exising plugins are loaded, and if one of
> the devices can be handled with a plugin, it appears in the list. It is
> evident that a same device can only be used by one plugin at a time,
> never more.

Nice try... but not evident at all... you think file-oriented, and it is
wrong: you shouldn't make too many assumptions on how drivers work. For
example, the current AVC driver uses ports, not device names... And
according to Georgi, a same port can be opened by several sources at the
same time.

> For audio, that is more complication: all existing plugins are loaded,
> but all devices will be usable by different plugins : OSS, ALSA, ESD.

* All _installed_ plugins are loaded... if the user installed both
oss&alsa, then yes, they'll get loaded.
* I don't think and ESD plugin would be wise: wasn't it you who said it
had bad performance that made it unsuitable?
* notice: if gm calls
PDeviceManager::LoadPlugin("/usr/lib/pwlib/sound/alsa.so"); before any
other use of a PDeviceManager methods, then the system plugins won't get
loaded (ie: not even the video ones), because it will see its plugins'
list will not be nil;

> It means that you will have the following in the list of available
> devices :
> - OSS /dev/dsp
> - ALSA /dev/dsp (the name will be different, but...)
> - ESound /dev/dsp
> 
> Using ALSA /dev/dsp as input (recording) with OSS /dev/dsp as output
> won't work. It means that in most cases, using the same device
> (/dev/dsp) with different plugins for output and input won't work.
> Notice that ALSA means here native ALSA support and not ALSA with OSS
> emulation.

Yes. The user will get the usual "device couldn't be opened, etc" error
message, will choose "OSS /dev/dsp" in both cases and it will work.

> I think that it is a bit complex for the user. So we have several
> possibilities :

I think at least the user will get an error message... why doesn't gm
warn when I choose /dev/sound/dsp as input, that there is no sound
coming from there?! I really think it should automatically try
/dev/sound/dsp1 and discover that there really is sound coming from
there! I think you're making way too much noise for something the user
will perhaps not even see (ie: the distribution will provide all
plugins, but will only make a well-chosen set the default: the plugins
that go well with the kernel it ships with!).

> - Add a command-line parameter in GM that returns the available plugins,
> and another one that permits to set the device to use in an hidden gconf
> key. That way the user will only have to do it if he wants to use
> something else than what his distribution ships. 

Not possible with the current manager API. A command-line parameter for
a gui app!? A hidden gconf!?

> - Add a box in the prefs, where the user chooses what plugin he wants to
> use. Problem here is that average users don't know what is ALSA or OSS
> and they shouldn't know it. They should just have something that works.

Not possible with the current manager API.

> - Tell to packagers in distributions to only package one plugin, the one
> they like.

No. Tell them to make a virtual sound plugins, that any sound plugin
will provide. Or to ship all plugins, but only install by default those
that fit their default kernel.

> - Propose all devices to the user, he will get an error popup during
> calls when it doesn't work. Problem here is that average users don't
> know what is ALSA or OSS and they shouldn't know it. They should just
> have something that works.

The average user will try another combination. Just like I did when I
didn't hear myself when I chose /dev/sound/dsp as input the first
time... I didn't know where my mic was, I looked for it my second guess
was right. And I had even no error message of gm to explain me I had
chosen something wrong!

> The first solution is perhaps the one I like the most. But we have more
> problems when we introduce ALSA :
> - the mixer devices settings in GnomeMeeting doesn't make sense anymore,
> only the player and recorder settings make sense, so there must be a way
> in GM to hide them when ALSA is used

It just means adding a plugin type and the corresponding api+code to the
manager...

> - OSS devices don't have a name, ALSA devices have a name

Well, it's the plugin job to take care of it.

> Any comments?

It would make sense to:
* add an API for programs, so that they can get the list of plugins (for
video/audio input/output), with a nice descriptive name (problem:
i18n?);
* make the automatic plugin loading more smart: currently, if no plugin
is loaded, it tries to load all of them. It would not be too difficult
to make it load only plugins of a specific type if there is none of that
kind yet. In that case, gm could load ALSA specifically, and OSS
wouldn't be autoloaded. Or the reverse.

I worked with two main goals in mind, that were:
* make it possible to use plugins in gm, with minimum source tampering;
* tamper as little as possible with pwlib (ie: mostly add things, and
not change the behaviour of what's already there);

It seems  you don't want the first after all!

> Julien, perhaps migrating my function that detects mixers to the plugin
> is a good idea. If you look at their code, it already detects the
> mixers, but there is no way to get the mixers list from the outside.

New mixer API for pwlib? It will be easy to add a new type of plugins:
* add the plugin type;
* add an API;
* write the functions to handle the API;
What's longer in all that is to get the mixer API for pwlib.

Snark