OpenAL timing of multiple sounds

Solar2D General Questions/Discussion
#1

Hi,

just wondering if the overall ouput is buffered (triggered sounds mixed together and played as a buffer) or each sound (and it’s timing) exists separately.

I know the system uses “best effort timing”, but it also mentions buffer underruns.

Mainly this is for multiple one-shot sounds playing at once.

Also with looping, is the looping of one sound seamless (if the sound is cut correctly)? (But triggering a different sound at the end of a loop, may not be seamless?)

thanks
j
[import]uid: 6645 topic_id: 4289 reply_id: 304289[/import]

#2

So at the OpenAL level, each sound is managed individually but it is a private implementation detail of an OpenAL implementation of how things are actually put together.

The buffer underrun warnings are only related to streaming samples. These occur because OpenAL makes us periodically feed it more data. If we don’t feed it enough data fast enough, OpenAL starves and you get a pause until we can feed it more data.

Pre-loaded samples don’t have to worry about this. (audio.loadSound())

Looping is just playing the same sound again. We providing a looping API parameter to help make this faster and easier. In theory, if you use our API, we have less function-call overhead to go through to play the sound again. And for pre-loaded samples, if you are looping infinitely, we can use OpenAL’s built-in looping parameters to avoid even more function-call overhead.

But in practice, you usually aren’t going to notice the difference in timing of a few more function calls.

I take it that you might be thinking about chaining sound effects one after another and hoping it sounds seamless. The one caveat is that we run things on multiple threads so there might be some additional unpredictable latency introduced for thread switching. I say give it a try and let us know how it works. You should use pre-loaded samples for lowest latency.

[import]uid: 7563 topic_id: 4289 reply_id: 14193[/import]

#3

Hi, thanks for the reply. I will try it when I can. I am a Flash developer so we have new features there for creating dynamic audio (mixing sounds etc and outputting in discrete chunks) using Event.SAMPLE_DATA. Since all sounds are premixed before going to the output using this method, if there is a CPU glitch it affects the whole sound, rather than individual parts of it, a bit like a skipping CD. I was just trying to work out if the OpenAL libraries were a High Level interface for this kind of system.

However, I assume Corona’s OpenAL is more like the Sound/SoundChannel system available in Flash. For a basic audio mixer where loops are constantly playing but can be muted on/off, this alternative can be used but is not as solid as the first method. I think I can get about 6-10 loops synced seamlessly in Flash continuously using the loop parameter, but essentially they all need to be running all the time in order to keep timing. I cant trigger one after the other without timing issues as the SOUND_COMPLETE event doesnt fire immediately

When I can get access to various devices I will try some examples in Corona to do similar and share my findings.

thanks
j
[import]uid: 6645 topic_id: 4289 reply_id: 14197[/import]

#4

So I personally don’t have a Flash background so I can’t really do a comparison. But the mental model of OpenAL comes from the high performance 3D game universe. It was developed about a decade ago and used in a bunch of high profile, high budget titles/engines like Quake and Unreal. As such, the focus is biased towards playing sounds fast as possible with optional 3D effects like position and Doppler. Some vendors also make hardware which provides hardware acceleration for OpenAL so the spec is also influenced by that.

So it might not be wise to attribute Flash behaviors to OpenAL. They probably have little in common except they both play sounds.

OpenAL itself does not have a callback/completion system built-in. That is something Corona provides. We do have to cross threads to provide a callback for you to hook into so there potentially could be some latency involved. However, the system as a whole is actually pretty lightweight so for most use cases, the latency is too small for anybody to notice. Only apps with the most stringent timing requirements might this become an issue.
[import]uid: 7563 topic_id: 4289 reply_id: 14206[/import]

#5

Thanks for the helpful responses.

I know it’s really down to testing in the end and seeing what works.

At the moment I’m just pushing the limits (albeit theoretcally at the moment!) to see what can be done and what can’t so I can tailor my projects accordingly.

regards
J [import]uid: 6645 topic_id: 4289 reply_id: 14207[/import]