[openal] openal Digest, Vol 31, Issue 2

Matthew Swartz matthew.w.swartz at gmail.com
Thu Aug 11 18:10:03 EDT 2016


Hi Chris Robinson,

Great work with OpenAL Soft, I really do love it :)

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.

On Thu, Aug 11, 2016 at 12:00 PM, <openal-request at openal.org> wrote:

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


More information about the openal mailing list