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

[Damien Sandras <dsandras seconix com>]

Le mar 12/08/2003 à 12:14, PUYDT Julien a écrit :
> 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.
> 

Then we have the same kind of problem than with audio. 

> * All _installed_ plugins are loaded... if the user installed both
> oss&alsa, then yes, they'll get loaded.

OK, imagine we have several plugins :
- arts
- alsa
- oss
- jack

Imagine you have 2 devices. Does that mean the user will see the 8
devices in his list? Yes and that is bad. What we need is a way to limit
the choice to one plugin only.

> * I don't think and ESD plugin would be wise: wasn't it you who said it
> had bad performance that made it unsuitable?

Indeed, but that was just an example of plugins. A saner plugin would be
a jack plugin.

> 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.

A good GUI must hide technical details from the user. See later.


> 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

I won't answer to that troll. I want a sane discussion, not ranting or
whining.


> 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.
> 

That doesn't solve the problem.


> 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!
> 

Because you had chosen something correct, there was simply no mic
connected to /dev/sound/dsp, plug one mic in the card and it will
work... That leads me to say that listing dsp* is something bad anyway.
We need to use real devices names. That's of course not possible with
OSS, but that is possible with ALSA.

> 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!
> 

The current approach doesn't minimize the amount of code changes in
GnomeMeeting if we want to do things correctly.

There are several problems with the current approach (having all plugins
usable concurrently) :
1) if we have x plugins and 2 devices, it will create a list of 2*x
possible devices, which is bad. The primary intent of adding plugins is
to easily add new plugins. I already see the possibility for
GStreamer/ALSA/Jack plugins. If you have 2 devices, it would at least
mean 8 items in the list.

2) If you have many items in the list, it will make things complicated
for the user to choose a combination. For only 4 plugins, with 2
devices, it makes 64 possibilities to try.

3) A good GUI hides implementation details to the user. The user
shouldn't have to know if he is using ALSA or OSS (and a big part
doesn't know) for example. He should just choose 'Sound Blaster Live' or
'Philips Webcam Internal Microphone'. 

4) Using a different plugin implies many others internal changes in
GnomeMeeting :
	* mixers won't make sense with all plugins
	* setting the microphone as recording source is different from 	one
plugin to another
	* setting the volume for recording and playing is different from
	one plugin to another

The last 2 can be additions to the API.

So 2 things really disturb me a lot with the current approach :
- number of devices explosion
- incompatibility between drivers

The solution is to get a list of possible devices by plugin. The user
chooses a plugin and gets the corresponding list of devices. 
Having all devices listed with their different drivers is a bad
solution. I've never seen that in any program, so I suppose I'm not the
only one to think this.

-- 
 _	Damien Sandras
(o-	GnomeMeeting: http://www.gnomemeeting.org/
//\	FOSDEM 2003:  http://www.fosdem.org
v_/_	H.323 phone:  callto://ils.seconix.com/dsandras seconix com