Re: non-realtime sound simulation (simulating only N msec per frame)

Chris Robinson <[email protected]>
Newsgroups gmane.comp.lib.openal
Message-ID <[email protected]>
On Tuesday 19 January 2010 12:21:22 pm [email protected] wrote:
> So here's the scenario: I am modifying a game I play (Alien Arena) which
>  uses openAL for sound. I am adding a feature which allows you to export
>  videos. The export feature lets you set a desired output framerate, then
>  it changes the main loop so that exactly 1000/framerate milliseconds are
>  simulated every frame. The idea is that you first record a demo normally,
>  then play it back and have it export the video.
> 
> Is there a way to do this with the audio in openAL as well? So if the
>  export framerate is 25, can I have openAL simulate 40 Milliseconds and
>  then just stop? Also, can I have it "render" the mixed PCM sound into a
>  buffer instead of (or as well as) playing it on the soundcard?

Hi. There isn't, unfortunately, a way to generate/record a specific amount of 
audio at a given time, or write it to a buffer. There have been ideas floated 
around about an extension to do that, however. It may be worth discussing, 
since this gets asked often.

It would actually not be too difficult to implement something like this in 
OpenAL Soft. But I'd like to get a consensus for the way other people would 
like to do it. FWIW, my idea would be to do something like this:

ALCdevice *dev = alcLoopbackOpenDevice();
ALCint attribs[] = {
    ALC_FREQUENCY, rate, ALC_FORMAT, format, 0
};
ALCcontext *ctx = alcCreateContext(dev, attribs);
alcMakeContextCurrent(ctx);
...make all your normal AL calls...

// Generate/capture the needed sample frames of audio
static uint64_t oldcount = 0;
uint64_t newcount = (uint64_t)CurrentFrame * rate / target_fps;

alcCaptureSamples(dev, sample_buffer, newcount-oldcount);
oldcount = newcount;

...all done...
alcMakeContextCurrent(NULL);
alcDestroyContext(ctx);
alcCloseDevice(dev);

The specified rate would be the sample rate of the generated audio (though it 
would actually be created "on demand"), and the format would be the sample 
format of the generated audio (following the same format and channel ordering 
rules as when used for alBufferData). If one or the other isn't specified, or 
the specified values can't be used "exactly", then context creation would 
fail.

All standard playback device queries and functions would work, and none of the 
capture queries and functions, with the exception of alcCaptureSamples to 
generate the audio.
_______________________________________________
Openal mailing list
[email protected]
http://opensource.creative.com/mailman/listinfo/openal
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.