[Openal-devel] Volume Control extension

[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"