public interface IAudioRenderSourceWhere a device gets the samples it is about to play.
No guide page documents this yet — the page shows what the code says about itself.
Remarks
Pull, not push. The device asks when it needs frames, on whatever thread it does its work on, and the source produces exactly that many. A push model would need a queue between the game and the device with a policy for what to do when it filled, and every audio API in existence is already a pull model underneath — a push API would be a queue wrapped around a queue.
Render runs on the audio thread and must not block. No locks a game thread can hold, no allocation, no I/O, no logging. That constraint is what shapes AudioEngine: control arrives as commands in a lock-free queue that Render drains, and results leave as counters it publishes.
Methods (2)
void Prepare(in AudioFormat format, int maxFrames)Told what the device settled on, before the first Render.
void Render(Span<float> destination, int frameCount)Fills a buffer with the next frames.
Used by (4)
- AudioEngineVixen.Audio
- IAudioDeviceVixen.Audio
- NullAudioDeviceVixen.Audio
- OpenALDeviceVixen.Audio.Backend.OpenAL