oh, and I forgot one part that is also bothering me : if I want to play a short audio at irregular intervals, should I call SDL_OpenAudio at the moment where I want to start playing, and start SDL_PauseAudio(0)at the beginning and leave it like that throughout the whole session ? Or should I call SDL_PauseAudio(1) whenever the sound is done ?
The typical use of SDL_PauseAudio() is just to enable the audio
callback once, as soon as you’re ready for action.
(An audio engine typically needs to allocate buffers, calculate filter
cores and whatnot, and you need to know the actual sample rate, buffer
size etc before you can do that. That’s why audio starts paused, so
you don’t have the callback firing in the middle of initialization.)
I find it difficult to understand which calls I need to use :
- SDL_LoadWAV is used to fetch the wav file from disk
Just a utility function. If you have your own loaders, use external
file I/O libs, you don’t need this.
- SDL_OpenAudio is used to initialize the callback
- SDL_PauseAudio is used to start the callback-loop
can I call SDL_CloseAudio from within the callback when my sound is done, and then have it re-open at a later time, or is this a slow/stupid thing to do ?
You might get away with this in some environments, but generally
speaking, this is asking for a crash or deadlock. Don’t do that!
Basically, you should assume that the audio callback runs in interrupt
context (which it actually does on some old SDL 1.2 platforms!), which
means no system calls, no memory allocations, no locks, no blocking
calls etc. (This is actually a pretty hairy subject…)
Should I call SDL_OpenAudio also at the beginning of the session ? how then can my callback know when to actually start playing ?
(That’s actually related to the aforementioned hairy subject.)
Typically, you’ll have an audio engine running via the callback, and
the application tells the callback what to do via some form of state
updates, messages or similar. This should preferably be lock free to
avoid priority inversion, which can result in audio glitches.
In very simple cases, you can get away with just having some atomic
values (integers typically) that the callback checks and responds to,
but this quickly becomes a lot more complicated than it sounds. (Start
by reading up on “race conditions” if you’re interested in that.)
What I usually do is use a lock-free FIFO or similar construct, to
safely pass proper “commands” to the audio callback. If the
application needs to know what the audio callback is up to, you can
use another lock-free FIFO to pass messages in the other direction.
There are a few different implementations of lock-free FIFOs around.
i?m really sorry to come over so un-educated
No worries. This subject is a lot more complicated than it may seem at
first, and that’s why most people just use some existing audio engine
with a higher level API instead. :-)On Fri, Apr 22, 2016 at 11:25 AM, jeroen clarysse <jeroen.clarysse at telenet.be> wrote:
//David Olofson - Consultant, Developer, Artist, Open Source Advocate
.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |