Re: [GnomeMeeting-devel-list] [BETA7] the "I'm in a real hurry" release
- From: PUYDT Julien <julien puydt laposte net>
- To: GnomeMeeting Devel Liste <gnomemeeting-devel-list gnome org>
- Subject: Re: [GnomeMeeting-devel-list] [BETA7] the "I'm in a real hurry" release
- Date: 12 Aug 2003 13:35:44 +0200
Le mar 12/08/2003 à 13:05, Damien Sandras a écrit :
> That's what I did.... Please mail me privately one giga patch containing
> all things.
Ok... I really wonder why you don't use dominance's nice source
packages. I use them to work more conveniently... Granted, it has the
side effect that the install: rule is bad...
> I'll work on an ALSA plugin tonight and see what happens with mixers in
> that case for example.
Nice.
> I think you should add the following functions to the API:
> - UseMixers (); returns TRUE if the current plugin needs mixers or not.
> That way I could show/hide them in GM on the fly when the user chooses
> another plugin.
> - SetPlayerVolume (PString dev, int vol); dev is a mixer or a device
> name, following if the plugin requires the use of mixers or not.
> - SetRecorderVolume ();
> - GetPlayerVolume ();
> - GetRecorderVolume ();
> - GetMixers ();
> PWLib also uses functions to Set and Get the volumes for the recorder
> and player but only when they are open. I think they appear in oss.cxx.
> But the API needs to be broken here when the plugins are used because it
> requires the device to be opened to be able to change the volume. In the
> case of OSS, it won't even always work, because devices do not always
> accept mixers ioctl's.
Well, once you opened the device, you have a nice PSoundChannel
instance, that will provide you all the PSoundChannel API.
The manager manages plugins, it doesn't provide device functions itself:
if you want to know whever a device has mixers, that feature shall be
added to the PSoundChannel API, and used like this:
sound_device = PDeviceManager::GetOpenedSoundDevice(...);
if(sound_device != NULL)
if(sound_device->HasMixers())
{ ... }
else
{ ... }
else
{ ... }
> And also work on real devices names instead of just /dev/dsp when
> available (ie not in the OSS case).
This can come after you have the basic functionnality in there: it is
just a matter of having two translating functions called from Open &
GetDeviceNames... Don't focus on it.
Snark
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]