Volume Control extension

[Guilherme Balena Versiani]

Hi,

I am using OpenAL in a VoIP spacialization environment and now I want to control the system sound volume. My first approach will be to create a library that works 'over' the current OpenAL interface (for Windows in a first work), as a low-level integration would require many engineering over the current code (for example, as I don't have access to the DirectSound device used by the implementation, I don't have a way to get back the index of the device to open the Windows mixer object -- unless I plug the volume code over the "Generic" implementation only). If you have any other information that could complement my level of information regarding this work, please tell me.

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)? I know and already researched the Enumeration Extension (including the code in SVN 'trunk' repository), and I know that OpenAL can add prefixes like "Generic Software", "Generic Hardware", "DirectSound3D" (deprecated) and "DirectSound" by inspecting the source code. But I don't know if there are another conventions from other OpenAL vendors... If you have such kind of information, it would be great too.

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?

Finally, does OpenAL community has interest to include this code in its core repository?

Regards,


_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Chris Robinson-5]

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.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Jason Daly]

Chris Robinson wrote:

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?
  

Most people consider this bad form, anyway.  Your app should handle its own gain, but leave other apps alone.  In most cases, you don't really know what else the user is doing, so you shouldn't presume to manipulate global settings.

This is the main reason OpenAL doesn't have this capability.  It's not really part of its job.  I suppose you could make the argument that a cross-platform audio mixing control library would have value, but that's outside the scope of OpenAL.

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.
  

They're designed to be a system component (or at least a system add-on).  That was the original intent of the "Router" implementation and the oalinst.exe redistributable installer.  The simplest thing to do is to bundle oalinst.exe with your installer and have it run during the installation process, or just point the user to where they can download it (http://connect.creativelabs.com/openal/Downloads/oalinst.zip)

--"J"


_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Guilherme Balena Versiani]

Hi,

Thank you all for your valuable answers. But I've done some
considerations below:

Jason Daly wrote:

> Chris Robinson wrote:
>> 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?
>>  
>
> Most people consider this bad form, anyway.  Your app should handle
> its own gain, but leave other apps alone.  In most cases, you don't
> really know what else the user is doing, so you shouldn't presume to
> manipulate global settings.
>
> This is the main reason OpenAL doesn't have this capability.  It's not
> really part of its job.  I suppose you could make the argument that a
> cross-platform audio mixing control library would have value, but
> that's outside the scope of OpenAL.

I understand everything you said from the point of view of the
programmers (being a programmer I share this same point of view when
inspecting application's architecture and system's organization).

But trying to think from the point of view of an user, there is a
necessity of control the volume of the application, just as you said,
independent from the other opened applications (not system-wide). Now,
if you see exactly what the gain control does, you will see the problem:
it is just a gain (increase/descrease of energy) relative to other
sources (please correct me if I am wrong, I am supposing based on what I
found in OpenAL open source code); so if the volume of the application
is low, for instance, there is no improvement of gain done on current
OpenAL that will satisfy the need of the user that wants to hear what
the program is playing louder. From my point of view, if OpenAL intends
to be a more valuable 3D audio environment, it should control the audio
volume. I know Windows XP does not have this kind of volume control
isolation per application; this feature appeared in Windows Vista. So my
idea is to make a kind of control that does the best, based on available
operating system resources, to attend what the user wants
(increase/descrease the sound that he/she is listening). The final work
should be a code similar to the "old OpenAL Windows open code", that
tries several mechanisms available on the system.

There is another simple necessity too for the OpenAL capture extension:
to control the microphone input volume (a kind of AGC for the input)
just before encode the audio, for instance, to be streamed -- this can
improve the audio quality perceived from the remote point. You can be
thinking "hey, just apply some gain (a multiplier) in the input", but if
you do, you will have a thing named "amplification of quantization noise"...

So, based in these two arguments, my opinion is that this kind of job is
inside the scope of OpenAL.

Regards,

--
*Guilherme Balena Versiani*
/Software Architect
ComunIP S/A
/
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Jason Daly]

Guilherme Balena Versiani wrote:

> I understand everything you said from the point of view of the
> programmers (being a programmer I share this same point of view when
> inspecting application's architecture and system's organization).
>
> But trying to think from the point of view of an user, there is a
> necessity of control the volume of the application, just as you said,
> independent from the other opened applications (not system-wide). Now,
> if you see exactly what the gain control does, you will see the problem:
> it is just a gain (increase/descrease of energy) relative to other
> sources (please correct me if I am wrong, I am supposing based on what I
> found in OpenAL open source code)

There are two places to set gain.  Each source has a gain setting, and
the listener also has a gain.  Adjusting the listener gain affects how
the audio from all the sources in that context is rendered.


> ; so if the volume of the application
> is low, for instance, there is no improvement of gain done on current
> OpenAL that will satisfy the need of the user that wants to hear what
> the program is playing louder. From my point of view, if OpenAL intends
> to be a more valuable 3D audio environment, it should control the audio
> volume.

I don't see why OpenAL needs to provide this.  First of all, the user
isn't interacting with OpenAL directly.  He or she is interacting with
an application.  The user likely already has two places to control the
volume, the mixer provided by the OS and/or sound drivers, and the
volume control knob on the speakers.  It's true that some applications
provide audio controls in the app as well, but usually these are to
control levels of things like music vs. speech vs. sound effects.

I don't recall seeing an app in recent years that controls the system
volume directly, except for content creation apps (sound editors,
etc.).  While you could write one of these using OpenAL, it's not really
what it was designed for.  Even if you did use OpenAL, there's nothing
saying the app couldn't use some other library to handle the mixer and
level adjustments.


> I know Windows XP does not have this kind of volume control
> isolation per application; this feature appeared in Windows Vista. So my
> idea is to make a kind of control that does the best, based on available
> operating system resources, to attend what the user wants
> (increase/descrease the sound that he/she is listening). The final work
> should be a code similar to the "old OpenAL Windows open code", that
> tries several mechanisms available on the system.
>  

That sounds like a great idea, but I don't think it belongs in OpenAL.

Let me give you an example.  You could come up with a library and API
that lets you handle color and gamma adjustments on your monitor, make
it compliant with various color standards (Pantone, Adobe, sRGB, etc.)
and make it cross-platform, so any application on any platform can use
it.  It could also be a great idea, but I'm pretty confident that the
OpenGL ARB would not accept it as an extension for OpenGL.  Although it
may be tangentially related, it has little to do with 3D graphics
rendering itself.

> There is another simple necessity too for the OpenAL capture extension:
> to control the microphone input volume (a kind of AGC for the input)
> just before encode the audio, for instance, to be streamed -- this can
> improve the audio quality perceived from the remote point. You can be
> thinking "hey, just apply some gain (a multiplier) in the input", but if
> you do, you will have a thing named "amplification of quantization noise"...
>
> So, based in these two arguments, my opinion is that this kind of job is
> inside the scope of OpenAL.
>  

I disagree.  OpenAL should handle the capture of the audio and nothing
else.  OpenAL isn't an entire application framework, it's just an audio
rendering library, with the additional convenience of being able to
capture two channels of audio.  Most of what's in OpenAL is there
because it has to be.  That is, implementing  feature X would be
impossible (or at least messy) if it were done externally.

This is the same reason OpenAL doesn't handle loading and decoding of
audio files, or streaming audio over the network, or other features like
this.  A lot of these things are handled elsewhere (like in ALUT or
ALURE).  This keeps OpenAL clean and avoids library bloat.  If your app
needs an additional feature, it can link with the library that has it,
while the other guy's app that doesn't need it can exclude it.

That's my opinion, anyway...

--"J"

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Guilherme Balena Versiani]

Hello all,

As promised, for those who really needs control over the system's mixer,
the project OpenAL mixer was launched and the first working version for
Windows is available at http://sourceforge.net/projects/openalmixer/. I
will work on documentation of its usage, besides the test project shows
everything that is needed to know. It was based on PortMixer project
made for PortAudio (thanks to Dominic Mazzoni at al), but it extends its
functions and work for one-way audio channel (for instance only for
audio rendering or audio capture). The selection of the right mixer is
based on current device name; if it matches any of current available
wave device, it is used; else, the default wave device is used instead.

This way, the "Generic Hardware" and "Generic Software" will use the
default wave device (input or output). For the "network devices" you
mentioned, I assume that the implementor knows what he/she is doing...

I won't discuss if this is important or not for OpenAL itself; the time,
and people (library users), will show us. Anyway, we need to pay
attention to Windows 7 movements towards to audio device routing
settings (http://www.xbitlabs.com/images/other/windows-7/p32.png).

Best regards,

Guilherme Balena Versiani.

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel