4

I'm working in iOS and have a simple OpenAL project running.

The difference to most openAL projects i've seen is that im not loading in a sound file. Instead I load an array of raw data into the alBufferData. Using a couple of equations I can load in data to produce white noise, sine and pulse waves. And all is working well.

My problem is that I need a way to modify this data whilst the sound is playing in real-time.

Is there a way to modify this data without having to create a new buffer (i tried the approach of creating a new buffer with new data and then use it instead but its nowhere near quick enough).

Any help or suggestions of other ways to accomplish this would be much appreciated.

Thanks

Simo
  • 2,172
  • 3
  • 19
  • 23

2 Answers2

2

I haven't done it on iOS, but with openAL on the PC what you would do is chain a few buffers together. Each buffer would have a small time period's worth of data. Periodically, check to see if the playing buffer is done, and if so, add it to a free list for reuse When you want to change the sound, write the new waveform into a free buffer and add it to the chain. You select the buffer size to balance latency and required update rate - smaller buffers allow faster response to changes, but need to be generated more often.

This page suggests that a half second update rate is doable. Whether you can go faster depends on the complexity of your calculations as well as on the overhead of the OS.

AShelly
  • 34,686
  • 15
  • 91
  • 152
1

Changing the data during playback is not supported in OpenAL.

However, you can still try it and see if you get acceptable defaults (though you'll be racing against the OpenAL playback mechanism, and any lag-outs in your app could throw it off, so do this at your own risk).

There's an Apple extension version of ALBufferData that tells OpenAL to use the data you give it directly, rather than making its own local copy. You set it up like so:

typedef ALvoid AL_APIENTRY (*alBufferDataStaticProcPtr) (const ALint bid,
                                                         ALenum format,
                                                         const ALvoid* data,
                                                         ALsizei size,
                                                         ALsizei freq);

static alBufferDataStaticProcPtr alBufferDataStatic = NULL;

alBufferDataStatic = (alBufferDataStaticProcPtr) alcGetProcAddress(NULL, (const ALCchar*) "alBufferDataStatic");

Call alBufferDataStatic() it like you would call alBufferData():

alBufferDataStatic(bufferId, format, data, size, frequency);

Since it's now using your sound data buffer rather than its own, you could conceivably modify that data and it won't be the wiser (provided you're not modifying things too close to where it's currently playing from in the buffer).

However, this approach is risky, since it depends on timing you're not fully in control of. To be 100% safe you'll need to use Audio Units.

Karl
  • 14,434
  • 9
  • 44
  • 61
  • Hmm, I never knew about that extension. Apparently [OpenAL in iOS has two Apple extensions: `alBufferDataStaticProcPtr` and `alcMacOSXMixerOutputRateProcPtr`](http://developer.apple.com/library/ios/#DOCUMENTATION/MusicAudio/Conceptual/CoreAudioOverview/CoreAudioEssentials/CoreAudioEssentials.html) – bobobobo May 16 '13 at 22:24
  • If you can actually scroll past the copyright disclaimer, there's a [.h](http://developer.apple.com/library/ios/#samplecode/oalTouch/Listings/Classes_MyOpenALSupport_h.html) and [.c](http://developer.apple.com/library/ios/#samplecode/oalTouch/Listings/Classes_MyOpenALSupport_c.html) file as part of the `oalTouch` project that show how to use these. – bobobobo May 16 '13 at 23:58