What does it mean when alGetError() (in OpenAL) returns -1 instead of a valid error code?

Question

I'm working on an iOS game where we create an OpenAL context on startup which exists for the life of the application. We allocate a pool of OpenAL sources. Each time a map is loaded the sound effects (.wav) are loaded into OpenAL buffers, and then we look for available sources when playing them. The only things that are loaded/unloaded are the buffers themselves.

After running for awhile some sounds just stop working when calling alPlaySource(). A call to alGetError() returns -1? Prior to the alPlaySource() call alGetError() returns 0.

score 2 · Answer 1 · edited May 23 '17 at 10:09

2

This is probably due to the fact that iOS limits the number of concurrent playing sources to 32.

See also: maximum number of OpenAL sound buffers on iPhone

edited May 23 '17 at 10:09

Community

1
1

answered Jul 06 '12 at 15:48

dpasca

21
1
4

We specifically limited the number of allocated buffers to 32. – Dec 12 '12 at 07:01
This may be the issue, but: returning -1 is not according to spec. – Bram Nov 26 '14 at 22:50

score 0 · Accepted Answer · answered Dec 12 '12 at 07:01

I think this was an extremely subtle memory leak resulting in some weird effects like the above. The code was based on some example code, ie SoundEngine which is known to be buggy and should not be used.

We ended up switching over to FMOD.

What does it mean when alGetError() (in OpenAL) returns -1 instead of a valid error code?

2 Answers2