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