From chris.kcat at gmail.com  Mon Jul  6 15:57:35 2015
From: chris.kcat at gmail.com (Chris Robinson)
Date: Mon, 06 Jul 2015 12:57:35 -0700
Subject: [openal] ALC_SOFT_HRTF proposal (update)
Message-ID: <559ADDAF.7080001@gmail.com>

Here's an update for the ALC_SOFT_HRTF extension proposal. The change is 
that {ALC_HRTF_SOFT,ALC_FALSE} explicitly requests no HRTF now, while 
{ALC_HRTF_SOFT,ALC_DONT_CARE_SOFT} is default behavior (autodetect). 
Current Git has been updated to reflect this. The alcGetIntegerv query 
for ALC_HRTF_SOFT will still only return ALC_TRUE or ALC_FALSE, though.

As always, feedback is welcome!
-------------- next part --------------
Name

    ALC_SOFT_HRTF

Contributors

    Chris Robinson

Contact

    Chris Robinson (chris.kcat 'at' gmail.com)

Status

    In progress.

Dependencies

    This extension is written against the OpenAL 1.1 specification.

Overview

    This extension allows an application to request HRTF mixing and determine
    the status of HRTF mixing. HRTF, or Head-Related Transfer Function, is a
    method of mixing 3D audio for true 3D panning, typically using predefined
    FIR filters designed to reproduce how a sound is affected by a listener's
    head as the sound waves travel around the head.

    As a 3D sound API, OpenAL's design allows implementations to render 3D
    audio using HRTF. In fact, a few well-known implementations can already do
    this without needing any input from the application. However, currently
    the OpenAL API has no concept of HRTF so there is no way to query if HRTF
    is being used, and no way for an application to provide an option to use
    it. This aims to fix that.

Issues

    Q: If implementations can already use HRTF, why is an extension needed?
    A: Although implementations can use HRTF, there is no way for the app to
       know if it's being used. At the very least, an app may want to alert
       the user to whether HRTF is being used or not, and why it's being used
       or not.

       Additionally, a user may not know how to enable HRTF through a given
       implementation's configuration, and it is not always possible for an
       implementation to detect when HRTF should be used. The request is only
       a hint however, so if an implementation needs to ignore it for whatever
       reason, it can, and still provide feedback to the app about why.

    Q: It is not unlikely for an implementation to be able to provide multiple
       different HRTFs for different purposes (head measurements, quality,
       etc). How is this handled?
    A: Currently, it isn't. An app simply requests HRTF and the implementation
       is responsible for picking one if multiple are available. The idea of
       enumerating and selecting from all available HRTFs was considered, but
       no design has yet been made.

    Q: What is the purpose of alcResetDeviceSOFT?
    A: An app will undoubtedly want the ability to enable and disable HRTF at
       runtime (e.g. in response to in-game option changes). The usual way of
       enabling HRTF would be with the attribute list to alcCreateContext,
       however this is clunky if audio playback is already started; either it
       would need to destroy the context then create a new one with the new
       parameters, or create a context just for the side-effect of changing
       the device properties and then not use it for anything. A method just
       to reset the device properties seems the most elegant solution, as it
       would not interrupt existing contexts, and it would not rely on side-
       effects of function behaviors which may not be reliable.

New Procedures and Functions

    ALCboolean alcResetDeviceSOFT(ALCdevice *device, const ALCint *attrList);

New Tokens

    Accepted as part of the <attrList> parameter of alcCreateContext and
    alcDeviceResetSOFT, and as the <paramName> parameter of alcGetIntegerv:

        ALC_HRTF_SOFT                            0x1992

    Accepted as part of the <attrList> parameter of alcCreateContext and
    alcDeviceResetSOFT, for the ALC_HRTF_SOFT attribute:

        ALC_DONT_CARE_SOFT                       0x0002

    Accepted as the <paramName> parameter of alcGetIntegerv:

        ALC_HRTF_STATUS_SOFT                     0x1993

    Possible results from a ALC_HRTF_STATUS_SOFT query:

        ALC_HRTF_DISABLED_SOFT                   0x0000
        ALC_HRTF_ENABLED_SOFT                    0x0001
        ALC_HRTF_DENIED_SOFT                     0x0002
        ALC_HRTF_REQUIRED_SOFT                   0x0003
        ALC_HRTF_HEADPHONES_DETECTED_SOFT        0x0004
        ALC_HRTF_UNSUPPORTED_FORMAT_SOFT         0x0005


Additions to Specification

    Resetting an open device

    After a device is opened for playback, an application may reset it to
    attempt changing the playback properties. To reset the device, use the
    function

    ALCboolean alcResetDeviceSOFT(ALCdevice *device, const ALCint *attrList);

    The device parameter is a handle to a valid playback device as returned by
    alcOpenDevice, otherwise an ALC_INVALID_DEVICE error is generated. The
    attrList is the same as what could be passed to alcCreateContext. The AL
    is allowed to ignore attribute values and combinations the device cannot
    support (e.g. if the device doesn't support the requested ALC_FREQUENCY
    value, another frequency value it does support may be set).

    On success the function returns ALC_TRUE, and on failure the function
    returns ALC_FALSE. Note that a return of ALC_TRUE does not indicate any
    attributes were honored, just that the device was successfully reset. If
    you need to know what the attributes are after a reset, query the device
    using alcGetIntegerv with the relevant attributes.


    HRTF mixing

    An application may request mixing using a Head-Related Transfer Function,
    or HRTF. HRTF can provide better spatial acuity when using headphones by
    using special filters designed to replicate how sounds are affected by the
    shape of the listener's head as they come in from a given direction. To
    request HRTF, specify the ALC_HRTF_SOFT attribute to alcCreateContext or
    alcResetDeviceSOFT with the value ALC_TRUE.

    ALCint attrs[] = {
        ALC_HRTF_SOFT, ALC_TRUE, /* request HRTF */
        0 /* end of list */
    };
    context = alcCreateContext(device, attrs);

    Specifying the value ALC_FALSE will request no HRTF mixing. The default
    value of ALC_DONT_CARE_SOFT will allow the AL to determine for itself
    whether HRTF should be used or not (depending on the detected device port
    or form factor, format, etc).

    Requesting HRTF mixing may cause the AL to reconfigure the device for a
    specific output mode and restrict the usable frequency values.

    A word of warning: although HRTF can sound great with headphones, it may
    result in increased resource usage and it may not sound very good with
    ordinary speakers, particularly if the user has surround sound output.
    Consequently, it is not a good idea to unconditionally request HRTF
    mixing. A good rule of thumb is to not specify an ALC_HRTF_SOFT attribute
    by default (or instead use the ALC_DONT_CARE_SOFT value), letting the AL
    autoselect it as appropriate, unless the user indicates otherwise.


    HRTF status query

    An easy way to query HRTF status is to simply call alcGetIntegerv with the
    ALC_HRTF_SOFT attribute. This will respond with ALC_TRUE if HRTF is in use
    on the device, or ALC_FALSE if not.

    More detailed status info can be obtained by calling alcGetIntegerv with
    the ALC_HRTF_STATUS_SOFT parameter. This may respond with one of the
    following values:

    ALC_HRTF_DISABLED_SOFT - HRTF is disabled (generic response).
    ALC_HRTF_ENABLED_SOFT - HRTF is enabled (generic response).
    ALC_HRTF_DENIED_SOFT - HRTF is disabled because it's not allowed on the
                           device. This may be caused by invalid resource
                           permissions, or other user configuration that
                           disallows HRTF.
    ALC_HRTF_REQUIRED_SOFT - HRTF is enabled because it must be used on the
                             device. This may be caused by a device that can
                             only use HRTF, or other user configuration that
                             forces HRTF to be used.
    ALC_HRTF_HEADPHONES_DETECTED_SOFT - HRTF is enabled because the device
                                        reported headphones.
    ALC_HRTF_UNSUPPORTED_FORMAT_SOFT - HRTF is disabled because the device
                                       does not support it with the current
                                       format. Typically this is caused by
                                       non-stereo output or an incompatible
                                       output frequency.

    This is not an exhaustive list; extensions may add more status values in
    the future, so an application must be prepared to handled unknown
    status values.

Errors

From dtvictorious at gmail.com  Fri Jul 17 10:20:30 2015
From: dtvictorious at gmail.com (Victorious)
Date: Fri, 17 Jul 2015 22:20:30 +0800
Subject: [openal] buffer questions
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAACQjwxak3O5ItHIkmtQBFDbCgAAAEAAAAC/+KoBMSgNAvK1PCK6C5vUBAAAAAA==@gmail.com>

Hi,

 

If a file is loaded into a buffer, is it safe for multiple sources to reuse
this buffer to play the same file? Each source may have different positions,
volumes, and start/pause/stop playback at different times.

 

How much data is there in each buffer object? I'm assuming that if you load
a file into it, it contains the uncompressed contents of the whole file, in
which case, how do I calculate the size in bytes of a .ogg after its been
decoded into a form openal-soft can work with? In the case of streaming with
Alure, what is the size set for each buffer?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openal.org/pipermail/openal/attachments/20150717/efa228a5/attachment.html>

From chris.kcat at gmail.com  Fri Jul 17 16:01:07 2015
From: chris.kcat at gmail.com (Chris Robinson)
Date: Fri, 17 Jul 2015 13:01:07 -0700
Subject: [openal] buffer questions
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAACQjwxak3O5ItHIkmtQBFDbCgAAAEAAAAC/+KoBMSgNAvK1PCK6C5vUBAAAAAA==@gmail.com>
References: <!&!AAAAAAAAAAAYAAAAAAAAACQjwxak3O5ItHIkmtQBFDbCgAAAEAAAAC/+KoBMSgNAvK1PCK6C5vUBAAAAAA==@gmail.com>
Message-ID: <55A95F03.6070807@gmail.com>

On 07/17/2015 07:20 AM, Victorious wrote:
> If a file is loaded into a buffer, is it safe for multiple sources to reuse
> this buffer to play the same file? Each source may have different positions,
> volumes, and start/pause/stop playback at different times.

Yep, that's entirely fine. A buffer represents the sound itself, while a 
source represents the playback state of a sound, so you can have 
multiple playback states referencing the same sound and each source will 
track its own position, volumes, etc.

Anything set on the buffer will be shared (such as loop points using 
AL_SOFT_loop_points), while anything set on the source is unique to the 
source.

> How much data is there in each buffer object? I'm assuming that if you load
> a file into it, it contains the uncompressed contents of the whole file, in
> which case, how do I calculate the size in bytes of a .ogg after its been
> decoded into a form openal-soft can work with? In the case of streaming with
> Alure, what is the size set for each buffer?

You can tell by querying the buffer's size:

ALint size;
alGetBufferi(buffer, AL_SIZE, &size);

That will give you the size in bytes of the stored audio samples.

Note that you don't have to decode the whole ogg into a single buffer if 
you know it's going to be long (e.g. for background music). You can use 
a source's buffer queue to only load small potions of it at a time.

From icculus at icculus.org  Sat Jul 25 19:02:32 2015
From: icculus at icculus.org (Ryan C. Gordon)
Date: Sat, 25 Jul 2015 19:02:32 -0400
Subject: [openal] Website is alive again...
Message-ID: <55B41588.4090504@icculus.org>


Thanks to zakk slater, we've got a working OpenAL website that isn't 
embarrassing now.

     http://openal.org/

Feedback welcome!

--ryan.


From metal.spark at yahoo.com  Sat Jul 25 19:19:01 2015
From: metal.spark at yahoo.com (N. N.)
Date: Sat, 25 Jul 2015 16:19:01 -0700
Subject: [openal] Website is alive again...
In-Reply-To: <55B41588.4090504@icculus.org>
Message-ID: <1437866341.79893.YahooMailBasic@web140104.mail.bf1.yahoo.com>

>On Sat, 25/7/15, Ryan C. Gordon <icculus at icculus.org> wrote:
> Thanks to zakk slater, we've got a working OpenAL website
> that isn't  embarrassing now.
> 
>      http://openal.org/
> 
> Feedback welcome!
> 
> --ryan.

Looks great!
However, shouldn't openalSoft be listed as well, since, it is the de facto replacement for openAL, with active development still going on?

I doubt Creative is going to do any updates themselves to openAL.





From metalcaedes at gmail.com  Sat Jul 25 19:40:41 2015
From: metalcaedes at gmail.com (Daniel Gibson)
Date: Sun, 26 Jul 2015 01:40:41 +0200
Subject: [openal] Website is alive again...
In-Reply-To: <55B41588.4090504@icculus.org>
References: <55B41588.4090504@icculus.org>
Message-ID: <55B41E79.7030103@gmail.com>

Awesome, this looks a lot better, thanks :-)

So, feedback:
* other OpenAL implementations, esp. OpenAL Soft, should be linked in 
the Downloads and/or Platforms pages
* is Apple's OpenAL implementation really Open Source? What kind of license?
* OpenAL Soft also supports Pulse Audio on Linux, maybe that should be 
mentioned as well.
* it should be mentioned that the only use of the Creative SDK is the 
included PDFs of the Programmers Guide the EFX Guide :-P
* related: Has anyone asked Creative if you could just provide the pdfs 
directly? The programmers guide used to be available for direct 
download, see 
http://web.archive.org/web/20130410143323/http://connect.creativelabs.com/openal/Documentation/Forms/AllItems.aspx
* Links to some OpenAL tutorials would be nice

Cheers,
Daniel

On 07/26/2015 01:02 AM, Ryan C. Gordon wrote:
>
> Thanks to zakk slater, we've got a working OpenAL website that isn't
> embarrassing now.
>
>      http://openal.org/
>
> Feedback welcome!
>
> --ryan.
>
> _______________________________________________
> openal mailing list
> openal at openal.org
> http://openal.org/mailman/listinfo/openal


From icculus at icculus.org  Sat Jul 25 22:46:58 2015
From: icculus at icculus.org (Ryan C. Gordon)
Date: Sat, 25 Jul 2015 22:46:58 -0400
Subject: [openal] Website is alive again...
In-Reply-To: <55B41E79.7030103@gmail.com>
References: <55B41588.4090504@icculus.org> <55B41E79.7030103@gmail.com>
Message-ID: <55B44A22.4040109@icculus.org>


> * other OpenAL implementations, esp. OpenAL Soft, should be linked in
> the Downloads and/or Platforms pages

Yeah, we took the (ancient!) list from the Wayback Machine, and it 
definitely needs updating. OpenAL-Soft not being on there is flatly 
criminal, I'll fix that now.

(Also worth noting: Emscripten by default provides apps with an 
implemenation of OpenAL, written in Javascript, believe it or not).

> * is Apple's OpenAL implementation really Open Source? What kind of license?

Here's the source code to the OpenAL that ships with Mac OS X 10.10.1:

     https://opensource.apple.com/source/OpenAL/OpenAL-54/

And it's LGPL, believe it or not:

 
https://opensource.apple.com/source/OpenAL/OpenAL-54/Source/OpenAL/OpenAL.txt

Apple doesn't offer revision control for it to the public, and I doubt 
they'd accept patches, but the source code is always published when new 
OS releases ship, and has been for more than a decade now.

> * OpenAL Soft also supports Pulse Audio on Linux, maybe that should be
> mentioned as well.

OpenAL Soft basically supports anything that makes sound; maybe we 
should just list this as "native" like the others?

> * it should be mentioned that the only use of the Creative SDK is the
> included PDFs of the Programmers Guide the EFX Guide :-P

This isn't my area of expertise. Is this really not useful at all any more?

> * Links to some OpenAL tutorials would be nice

Agreed, send me links, everyone!

--ryan.



From metalcaedes at gmail.com  Sat Jul 25 23:31:17 2015
From: metalcaedes at gmail.com (Daniel Gibson)
Date: Sun, 26 Jul 2015 05:31:17 +0200
Subject: [openal] Website is alive again...
In-Reply-To: <55B44A22.4040109@icculus.org>
References: <55B41588.4090504@icculus.org> <55B41E79.7030103@gmail.com>
 <55B44A22.4040109@icculus.org>
Message-ID: <55B45485.4070902@gmail.com>

On 07/26/2015 04:46 AM, Ryan C. Gordon wrote:
>
>> * other OpenAL implementations, esp. OpenAL Soft, should be linked in
>> the Downloads and/or Platforms pages
>
> Yeah, we took the (ancient!) list from the Wayback Machine, and it
> definitely needs updating. OpenAL-Soft not being on there is flatly
> criminal, I'll fix that now.

Thanks!

>
> (Also worth noting: Emscripten by default provides apps with an
> implemenation of OpenAL, written in Javascript, believe it or not).

That's kinda insane. And that works?

>
>> * is Apple's OpenAL implementation really Open Source? What kind of
>> license?
>
> Here's the source code to the OpenAL that ships with Mac OS X 10.10.1:
>
>      https://opensource.apple.com/source/OpenAL/OpenAL-54/
>
> And it's LGPL, believe it or not:
>
>
> https://opensource.apple.com/source/OpenAL/OpenAL-54/Source/OpenAL/OpenAL.txt
>

I guess they were to lazy to create their own OpenAL implementation, so 
they're based off Creatives code just like OpenAL-Soft ;-)

>
> Apple doesn't offer revision control for it to the public, and I doubt
> they'd accept patches, but the source code is always published when new
> OS releases ship, and has been for more than a decade now.
>
>> * OpenAL Soft also supports Pulse Audio on Linux, maybe that should be
>> mentioned as well.
>
> OpenAL Soft basically supports anything that makes sound; maybe we
> should just list this as "native" like the others?

Yeah, I guess that would be easiest.
I think even Jack is supported by now (or was that just an experimental 
branch?)

>
>> * it should be mentioned that the only use of the Creative SDK is the
>> included PDFs of the Programmers Guide the EFX Guide :-P
>
> This isn't my area of expertise. Is this really not useful at all any more?

Not 100% sure. The guides are definitely very useful (much better than 
just the spec).
As creative doesn't seem to be interested in OpenAL anymore, the SDK 
isn't maintained, no idea how well it even works for modern Windows/MSVC 
versions.
In the rare  cases I compile stuff that uses OpenAL for Windows, I use 
OpenAL-Soft.

>
>> * Links to some OpenAL tutorials would be nice
>
> Agreed, send me links, everyone!

Some I found:
http://www.gamedev.net/page/resources/_/technical/game-programming/a-guide-to-starting-with-openal-r2008
http://www.edenwaith.com/products/pige/tutorials/openal.php

Don't know how great they really are, I don't even remember which ones I 
used when I learned a bit about OpenAL (possibly I just read examples 
and Creative's Programmers Guide).

Cheers,
Daniel

From mjt at cltn.org  Sun Jul 26 14:45:23 2015
From: mjt at cltn.org (OKUMURA Yuki)
Date: Mon, 27 Jul 2015 03:45:23 +0900
Subject: [openal] Website is alive again...
In-Reply-To: <55B44A22.4040109@icculus.org>
References: <55B41588.4090504@icculus.org> <55B41E79.7030103@gmail.com>
 <55B44A22.4040109@icculus.org>
Message-ID: <CAG1-Us3RfB9G1prm4virKOf_wWJ0Wa9H2qEjH5p45wpR12R15Q@mail.gmail.com>

2015-07-26 11:46 GMT+09:00 Ryan C. Gordon <icculus at icculus.org>:
- snip -
> Yeah, we took the (ancient!) list from the Wayback Machine, and it
> definitely needs updating. OpenAL-Soft not being on there is flatly
> criminal, I'll fix that now.

Now we can see OpenAL-Soft in the "Links" section. How about other 2
which are mentioned in the Wikipedia article(Rapture3D and AeonWave)?

> This isn't my area of expertise. Is this really not useful at all any more?

Aside historical interests:

- Creative still bundles their OpenAL stack with SoundBlaster
products. So these can be used as a SDK for it.

- CMedia's GX(Bundled with ASUS cards such as XONAR U3) can enable
DirectSound3D on Win7 or later.
  Since Creative OpenAL includes DirectSound3D wrapper as "Generic
Hardware" backend,
  we can use CMedia spatializer or EFX implementation through OpenAL API.
http://storage.osdev.info/pub/idmjt/diaryimage/1503/neta150314l1.png

From dtvictorious at gmail.com  Tue Jul 28 13:30:57 2015
From: dtvictorious at gmail.com (Victorious)
Date: Wed, 29 Jul 2015 01:30:57 +0800
Subject: [openal] API redesign for ease of use?
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAACQjwxak3O5ItHIkmtQBFDbCgAAAEAAAABpbvsWmJrBDu33a8kCjGpYBAAAAAA==@gmail.com>

Hi,

OpenAl-soft is currently compatible with the original OpenAl spec. Its c-style API is not as user-friendly as it could be; for example, having to know which variant of alSourcei, alSourcef, etc to use and constants to modify properties. Functions also don't return any errors encountered, requiring you to explicitly check for it. See these posts as well:

http://camlorn.net/posts/april2014/shortcomings-of-openal.html
http://camlorn.net/posts/december2014/horror-of-audio-output.html

Has an API redesign been considered? How important would compatibility  with the spec be? 


From metalcaedes at gmail.com  Tue Jul 28 14:56:48 2015
From: metalcaedes at gmail.com (Daniel Gibson)
Date: Tue, 28 Jul 2015 20:56:48 +0200
Subject: [openal] API redesign for ease of use?
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAACQjwxak3O5ItHIkmtQBFDbCgAAAEAAAABpbvsWmJrBDu33a8kCjGpYBAAAAAA==@gmail.com>
References: <!&!AAAAAAAAAAAYAAAAAAAAACQjwxak3O5ItHIkmtQBFDbCgAAAEAAAABpbvsWmJrBDu33a8kCjGpYBAAAAAA==@gmail.com>
Message-ID: <55B7D070.5030904@gmail.com>

On 07/28/2015 07:30 PM, Victorious wrote:
> Hi,
>
> OpenAl-soft is currently compatible with the original OpenAl spec. Its c-style API is not as user-friendly as it could be; for example, having to know which variant of alSourcei, alSourcef, etc to use and constants to modify properties. Functions also don't return any errors encountered, requiring you to explicitly check for it. See these posts as well:
>
> http://camlorn.net/posts/april2014/shortcomings-of-openal.html
> http://camlorn.net/posts/december2014/horror-of-audio-output.html
>
> Has an API redesign been considered? How important would compatibility  with the spec be?
>

Many of these problems sound like they could be "fixed" by writing a 
wrapper around OpenAL with a user-friendlier API (whatever it may look 
like).

Cheers,
Daniel


From chris.kcat at gmail.com  Tue Jul 28 23:47:48 2015
From: chris.kcat at gmail.com (Chris Robinson)
Date: Tue, 28 Jul 2015 20:47:48 -0700
Subject: [openal] API redesign for ease of use?
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAACQjwxak3O5ItHIkmtQBFDbCgAAAEAAAABpbvsWmJrBDu33a8kCjGpYBAAAAAA==@gmail.com>
References: <!&!AAAAAAAAAAAYAAAAAAAAACQjwxak3O5ItHIkmtQBFDbCgAAAEAAAABpbvsWmJrBDu33a8kCjGpYBAAAAAA==@gmail.com>
Message-ID: <55B84CE4.3010707@gmail.com>

On 07/28/2015 10:30 AM, Victorious wrote:
> Hi,
>
> OpenAl-soft is currently compatible with the original OpenAl spec.
> Its c-style API is not as user-friendly as it could be; for example,
> having to know which variant of alSourcei, alSourcef, etc to use and
> constants to modify properties. Functions also don't return any
> errors encountered, requiring you to explicitly check for it.

The need for type-specific functions is an unavoidable issue since C 
doesn't have function overloading (well, C11 kind of does with _Generic, 
but support for that is unfortunately not good enough to rely on). C++ 
and the like can, but a wrapper can easily handle that... though if 
you're building a wrapper, you'd probably want it to be a bit higher level.

Functions not returning errors is an explicit design decision; the idea 
is you're not supposed to generate errors in the first place since the 
input parameters are known and their limits are well-defined (so rather 
than reacting to errors from bad input, just don't generate bad input). 
The only errors really out of your control is out-of-memory*, but at 
that point you're in deeper trouble than just with OpenAL.

* There is also potential unpredictable errors with source playback when 
sources use shared system resources, which should only really effect 
hardware drivers, but I do wish either the API or spec was cleaner about 
that.

Though if/when you check for errors, it would ideally be after a number 
of calls, like:

alSource3f(source, AL_POSITION, pos);
alSource3f(source, AL_DIRECTION, dir);
alSourcef(source, AL_GAIN, gain);
...
alSourcei(source, AL_BUFFER, buffer);
ALenum err = alGetError();
if(err != AL_NO_ERROR)
    oops();
alSourcePlay(source);

Similarly, when updating a property you're more than likely going to 
update more than one source (e.g. it's not likely only a single source 
will move in a frame), so it's much more efficient to do it after 
they've all been updated rather than checking each individual call.


For debug purposes, I agree that it's useful for more exact information. 
With OpenAL Soft, there is a feature that can be enabled with the 
ALSOFT_TRAP_ERROR environment variable. With that set to "1", it will 
generate a breakpoint exception (or SIGTRAP under non-Windows) within 
the call that made the error, which will cause a debugger to break. With 
a debug build of OpenAL Soft, you can then inspect the backtrace to see 
which specific call generated the error, as well as the input parameters 
that caused it.

A more generic solution, something like GL_KHR_debug, has been 
suggested, and someone was willing to write up an extension spec, but it 
hasn't been finished yet.

> http://camlorn.net/posts/april2014/shortcomings-of-openal.html

I'd agree with this in that having one error code per context is an 
issue when doing certain kinds of multi-threaded work. I'd like to make 
an extension that allows apps to enable thread-local errors, so one 
context would have different error states in different threads.

The (the lack of) callbacks has its own issues, though. In the given 
example of knowing when a source stops, there's the issue that a source 
becomes stopped in the mixer after its been mixed and its offset 
updated, and the mixer is not where you want to be running random user 
code. This means the event would have to be marshaled to a separate 
thread that deals solely with calling user code for such events.

Additionally, most user code likely won't appreciate being called at 
random times and in parallel to other code. This would necessitate 
either the event being marshaled again from the user callback to 
someplace the app can safely deal with it, or using mutex locks to 
protect what it needs to access, or ensuring the callbacks are called at 
a specific time.

This isn't to say there wouldn't be a benefit, but it would need some 
consideration between what can be realistically achieved, and what apps 
can efficiently work with.

> Has an API redesign been considered? How important would
> compatibility  with the spec be?

If compatibility is broken, then I'd prefer there to be a clean break 
with all aspects of the API reconsidered, as well as a change to the 
header and lib names so that both the old API and new could co-exist. 
Either that, or some kind of deprecation/compatibility mechanism like in 
OpenGL 3. Existing apps must continue to work, and it would be 
beneficial for new apps to select which they want to use.

From dtvictorious at gmail.com  Thu Jul 30 02:55:03 2015
From: dtvictorious at gmail.com (Victorious)
Date: Thu, 30 Jul 2015 14:55:03 +0800
Subject: [openal] number of maximum sources. was: distance model
	questions
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAACQjwxak3O5ItHIkmtQBFDbCgAAAEAAAANIKjjM0nBNGsjYzDYFj+WsBAAAAAA==@gmail.com>

How was the limit of 255 mono and 1 stereo source chosen? Also, I'd like to increase this for stereo sources e.g 1 stereo source for background music, another stereo source for environmental ambient sounds. 

-----Original Message-----
From: openal [mailto:openal-bounces at openal.org] On Behalf Of Chris Robinson
Sent: Thursday, May 28, 2015 6:18 PM
To: openal mailing list
Subject: Re: [openal] distance model questions

On 05/28/2015 02:50 AM, Victorious wrote:
> That worked like a charm, thanks.
>
> If the gain is set to 0, it is completely muted. Is the source still 
> considered playing?

Yes. Certain steps may be skipped in the mixing pipeline for such sources, but as far as the app sees it plays normally (its offset will continue to increment, buffers will become processed, etc).

> On a related question, what is the maximum number of sounds that can 
> be played on windows 8.1?

OpenAL Soft has a practical limit of 256 simultaneous sources (the same maximum that can be allocated). It's all done in software, so the OS doesn't affect it.

Other implementations may have their own limits based on whatever criteria it uses. You can query this limit calling alcGetIntegerv with ALC_MONO_SOURCES and ALC_STEREO_SOURCES (you're guaranteed to be able to play the given number of mono sources and stereo sources simultaneously).
_______________________________________________
openal mailing list
openal at openal.org
http://openal.org/mailman/listinfo/openal


From chris.kcat at gmail.com  Thu Jul 30 06:29:39 2015
From: chris.kcat at gmail.com (Chris Robinson)
Date: Thu, 30 Jul 2015 03:29:39 -0700
Subject: [openal] number of maximum sources. was: distance model
	questions
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAACQjwxak3O5ItHIkmtQBFDbCgAAAEAAAANIKjjM0nBNGsjYzDYFj+WsBAAAAAA==@gmail.com>
References: <!&!AAAAAAAAAAAYAAAAAAAAACQjwxak3O5ItHIkmtQBFDbCgAAAEAAAANIKjjM0nBNGsjYzDYFj+WsBAAAAAA==@gmail.com>
Message-ID: <55B9FC93.9060009@gmail.com>

On 07/29/2015 11:55 PM, Victorious wrote:
> How was the limit of 255 mono and 1 stereo source chosen? Also, I'd
> like to increase this for stereo sources e.g 1 stereo source for
> background music, another stereo source for environmental ambient
> sounds.

You can request a specific number of stereo sources during context creation.

ALCint attr[3] = {
     ALC_STEREO_SOURCES, 2,
     0 /* end-of-list */
};
context = alcCreateContext(device, attr);

For OpenAL Soft, this will result in a "limit" of 254 mono sources and 2 
stereo sources. Though these are only soft limits... OpenAL Soft 
ultimately doesn't care how many non-mono sources you play; as long as 
you have a source ID generated, you can play something with it. But 
other implementations may reduce the number of sources you can play for 
each stereo source playing above the specified limit.

Personally, I'd like to see these separate mono/stereo source limits 
removed. I understand why it exists (certain implementations have a hard 
limit on the number of simultaneous voices, particularly hardware, and a 
single source doesn't necessarily map to a single voice, so increasing 
the stereo source count may take away extra mono sources, and so on), 
but it's extremely clunky because an app doesn't necessarily know how 
many stereo sources they'll play at once, and 4+ channel sources aren't 
accounted for at all. There has to be a better way to handle the issue.


As for why there's the 256 (255+1) limit with OpenAL Soft, it's partly a 
hold-over (IIRC, that's what both Creative's software driver and the old 
SI had), but also partly precautionary (I remember certain old tutorials 
suggesting that you could generate sources in a loop and just stop when 
it fails to create any more; if there was no source limit, this would 
cause such an app to lock up while it eats up all the system memory). 
There are things I could do to remove the limit without risking poorly 
programmed apps breaking, it would just require interested apps to be a 
bit proactive.