[Openal-devel] Volume Control extension

[Chris Robinson]

On Tuesday 21 July 2009 7:16:09 pm Guilherme Balena Versiani wrote:
> Hi,
> 
> I am using OpenAL in a VoIP spacialization environment and now I want
> to control the system sound volume.

Normally, you'd set the listener's gain to control the output volume of the 
app, or the source gain to control the volume of the individual sources. It 
won't affect other applications, but is there a reason you need to?

> Exploring this high-level integration, I found the problem: how do I
> know exactly (programatically speaking) the name of the sound device
> being used in current context (without OpenAL prefixes)?

You can't, really. The device doesn't need to be on the same system (eg. it 
can be over a network), and a device doesn't even need to exist (eg. if output 
is writing to a file). It's not really safe to assume an OpenAL device is one 
system device.

> I would like to understand how this work can be licensed. I know I need
> to put this code Open Source, so other people can contribute, but I
> need to clarify how the license can be composed, as I am using code
> from PortMixer as well (from Audacity source code, thanks to Dominic
> Mazzoni, Augustus Saunders and Leland Lucius). May I use both licenses
> (OpenAL/PortMixer) in the same source code?

The current Windows DLLs are closed source with a proprietary license, 
although they freely allow dynamic linking and redistribution of the DLLs 
without having to do anything special. OpenAL Soft and the old Windows code 
are LGPL. The old OSX code is under an X11/MIT-like license, but I think the 
current code is closed source now, too.

It looks like PortMixer is GPL (?), in which case the LGPL and X11-like 
licenses should be fine with it (though any sources from them would be 
distributed under the GPL terms as a derivative work). OSX's OpenAL could 
probably be considered a system component, so it should be alright to use even 
though it's not open.

I don't know if Creative's Windows DLLs can be considered a system component, 
though they do install into the system directory (system32 and/or syswow64). 
OpenAL Soft does work on Windows though, and is ABI-compatible, so you can 
always use that if an existing OpenAL isn't present on the system.