<div dir="ltr">Hi Chris Robinson,<div><br></div><div>Great work with OpenAL Soft, I really do love it :)</div><div><br></div><div>The solution you offered works well enough at the moment, but an extension such as that would be very welcome. Basically, a transition to something like FMOD would be a huge task, so I'm really hoping OpenAL Soft pulls off more features such as this. Stereo sources for pretty much everything would be great if possible. Also, I may be wrong here, but do you support the Opus format (I'm feeling too lazy to check atm)? If not, that would be a serious advantage as Opus seems like a great format to pick over Ogg.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 11, 2016 at 12:00 PM,  <span dir="ltr"><<a href="mailto:openal-request@openal.org" target="_blank">openal-request@openal.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send openal mailing list submissions to<br>
        <a href="mailto:openal@openal.org">openal@openal.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="http://openal.org/mailman/listinfo/openal" rel="noreferrer" target="_blank">http://openal.org/mailman/<wbr>listinfo/openal</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:openal-request@openal.org">openal-request@openal.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:openal-owner@openal.org">openal-owner@openal.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of openal digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Re: Extending max source gain (Ethan Lee)<br>
   2. Re: Extending max source gain (Chris Robinson)<br>
   3. Re: 3d sound? (Chris Robinson)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Wed, 10 Aug 2016 13:50:01 -0400<br>
From: Ethan Lee <<a href="mailto:flibitijibibo@flibitijibibo.com">flibitijibibo@flibitijibibo.<wbr>com</a>><br>
To: <a href="mailto:openal@openal.org">openal@openal.org</a><br>
Subject: Re: [openal] Extending max source gain<br>
Message-ID: <<a href="mailto:8562c59a-81d3-ae2d-d846-a9ec97c90170@flibitijibibo.com">8562c59a-81d3-ae2d-d846-<wbr>a9ec97c90170@flibitijibibo.com</a><wbr>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
My only real concern is the possibility of breaking existing behavior<br>
for older applications. That would only ever apply if AL_MAX_GAIN's<br>
default was changed, but as long as that remains at 1.0f then we can<br>
just allow up to FLT_MAX and not affect existing code. Something like an<br>
alGetFloat(AL_MAX_GAIN_LIMIT_<wbr>SOFT) would work for us in FNA, though that<br>
kind of limitation may as well apply to AL_MIN_GAIN too since we're<br>
thinking about MAX.<br>
<br>
-Ethan<br>
<br>
On 08/10/2016 12:00 PM, <a href="mailto:openal-request@openal.org">openal-request@openal.org</a> wrote:<br>
> I've had a few requests for this now, and have always been a bit stumped<br>
> by the design decision. Currently, according to the spec, the source's<br>
> AL_GAIN property can be set to anything >= 0, including 2, 4, etc.<br>
> However, sources also have the AL_MAX_GAIN property which clamps the<br>
> source's gain, but can only be set up to 1, meaning a source's gain will<br>
> always be clamped to 1 even though an app can set it to something greater.<br>
><br>
> Another thing is that the spec says (section 4.1, under AL_GAIN):<br>
> "the implementation is free to clamp the total gain (effective gain<br>
> per-source multiplied by the listener gain) to one to prevent overflow."<br>
> This further makes me wonder why AL_MAX_GAIN is limited to 1, since<br>
> implementations are allowed to implicitly clamp the total as needed anyway.<br>
><br>
> Currently, it is possible to work around this limitation by increasing<br>
> the listener's AL_GAIN above 1. Since the listener gain is applied after<br>
> clamping, a source's effective gain can be made greater than 1 if the<br>
> implementation doesn't implicitly clamp the total (and if it does, it's<br>
> still as loud as it can be). This workaround is pretty hacky, though.<br>
><br>
> I'd like to propose the following. Allow AL_MAX_GAIN (and AL_MIN_GAIN,<br>
> since it's a companion property) to be set to values greater than 1.<br>
> Since the implementation can clamp the total anyway, why not FLT_MAX?<br>
><br>
> Further, it may be useful to have a query (retrieved via alGetFloat and<br>
> friends) to specify the total maximum gain a source may be clamped to by<br>
> the implementation, rather than leaving it as a hidden detail. That way,<br>
> an app can know what limits there are for the combined gains, such that<br>
> increasing it beyond said limit won't make it any louder.<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 10 Aug 2016 14:03:01 -0700<br>
From: Chris Robinson <<a href="mailto:chris.kcat@gmail.com">chris.kcat@gmail.com</a>><br>
To: openal mailing list <<a href="mailto:openal@openal.org">openal@openal.org</a>><br>
Subject: Re: [openal] Extending max source gain<br>
Message-ID: <<a href="mailto:f89571f8-d999-5232-40c0-dd5931f8bbf9@gmail.com">f89571f8-d999-5232-40c0-<wbr>dd5931f8bbf9@gmail.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
On 08/10/2016 10:50 AM, Ethan Lee wrote:<br>
> My only real concern is the possibility of breaking existing behavior<br>
> for older applications. That would only ever apply if AL_MAX_GAIN's<br>
> default was changed, but as long as that remains at 1.0f then we can<br>
> just allow up to FLT_MAX and not affect existing code.<br>
<br>
Yes, the default would remain 1.0f for compatibility. This would just<br>
increase the range it's allowed to be set to.<br>
<br>
> Something like an<br>
> alGetFloat(AL_MAX_GAIN_LIMIT_<wbr>SOFT) would work for us in FNA, though that<br>
> kind of limitation may as well apply to AL_MIN_GAIN too since we're<br>
> thinking about MAX.<br>
<br>
Note that the queried max limit would be the implicit clamping level an<br>
implementation may do after the final volume is calculated, not strictly<br>
how high the source's AL_MAX_GAIN property can go. I don't imagine an<br>
implementation will have a minimum volume clamp like it may have a<br>
maximum volume clamp. I suppose there could be a query for the minimum<br>
non-0 volume before it just skips rendering and goes silent, though I<br>
don't know how useful that would be.<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 10 Aug 2016 14:48:25 -0700<br>
From: Chris Robinson <<a href="mailto:chris.kcat@gmail.com">chris.kcat@gmail.com</a>><br>
To: openal mailing list <<a href="mailto:openal@openal.org">openal@openal.org</a>><br>
Subject: Re: [openal] 3d sound?<br>
Message-ID: <<a href="mailto:94d717b8-f569-d3a0-9818-60867856034b@gmail.com">94d717b8-f569-d3a0-9818-<wbr>60867856034b@gmail.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
On 08/10/2016 05:48 AM, Matthew Swartz wrote:<br>
> Hi,<br>
> I've been using openal soft in my project for a while now, but I guess I'm<br>
> a bit confused about a couple of features.<br>
><br>
> I want to use 3d sound positioning in my game, as well as have stereo audio<br>
> sources that have proper distance functions so it doesn't always sound like<br>
> it's playing right at the player.<br>
<br>
Hi.<br>
<br>
OpenAL (and OpenAL Soft) doesn't apply distance attenuation to<br>
multi-channel sources. However, you can simulate it by changing the<br>
source's AL_GAIN given the distance between the source and listener.<br>
Where you'd normally set the position, instead set the gain based on the<br>
distance:<br>
<br>
ALfloat dist = distance(mPos, ListenerPos);<br>
if(dist <= mRefDist)<br>
     alSourcef(mSource, AL_GAIN, mVolume);<br>
else<br>
     alSourcef(mSource, AL_GAIN, mVolume * (mRefDist / dist));<br>
<br>
Where mRefDist is what you set on AL_REFERENCE_DISTANCE (default: 1.0f),<br>
mVolume is the normal volume the source would have without distance<br>
attenuation, mPos and ListenerPos are the up-to-date positions for the<br>
sound source and listener, and distance() calculates the distance<br>
between two 3D points. This is effectively what OpenAL Soft would do<br>
internally.<br>
<br>
I can consider adding an extension which would do this automatically.<br>
Something like<br>
alSourcei(mSource, AL_MC_DISTANCE_ATTENUATION, AL_TRUE);<br>
which would cause the source to calculate distance-related attenuation<br>
for stereo, quad, rear, 5.1, 6.1, 7.1, and b-format sources (mono would<br>
be unaffected by this extension, and this would only affect attenuation,<br>
not panning/rotation; stereo has AL_EXT_STEREO_ANGLES for that, and<br>
b-format comes with its own property for it).<br>
<br>
I wouldn't mind hearing from others if there's any concerns about this idea.<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
openal mailing list<br>
<a href="mailto:openal@openal.org">openal@openal.org</a><br>
<a href="http://openal.org/mailman/listinfo/openal" rel="noreferrer" target="_blank">http://openal.org/mailman/<wbr>listinfo/openal</a><br>
<br>
------------------------------<br>
<br>
End of openal Digest, Vol 31, Issue 2<br>
******************************<wbr>*******<br>
</blockquote></div><br></div>