How does the audio plugin host example actually tick

[daniel]

@zax

I have not been able to figure out where or what actually runs the whole system.

As I understand it it’s the AudioIODeviceCallback::audioDeviceIOCallback that is called by the audio driver to fill an AudioBuffer with sample data.

If there was the inheritance diagram available on the API doc (samuels alternative doc), you could see, that either AudioProcessorPlayer or AudioSourcePlayer are possible callbacks for the audio driver.

@zax

I’m assuming that my to-be rendering thread could not operate on the graph on the same time than the example is running it in realtime

The problem is, if you have connected it to an AudioSource, then each time getNextAudioBlock advances the played material, so you cannot call this from two separate threads without creating a mess.

@zax

create my own thread for offline rendering that’d call processBlock for the nodes as fast as they can

In this case be sure not to use any BufferingAudioSource, because they will deliver silence, if they didn’t get the chance to buffer new data while the last block gets played back.

I suggested once a wait method, which I called like:

if (isNonRealtime())
    waitForNextAudioBlockReady (info);
getNextAudioBlock (info);

That way I can use the same sources and spread the loading on different cores via TimeSliceThreads.

Here is the wait method:

BufferingAudioSource and non-realtime: waitForNextAudioBlock (with code)

I implemented this and it works for me: /** Wait for buffer ready. This will block until the buffer is prepared. DO NOT USE IN REALTIME! */ bool BufferingAudioSource::waitForNextAudioBlockReady (const AudioSourceChannelInfo& info, const uint32 sleepMiliSecs, const uint32 timeout) { if (nextPlayPos + info.numSamples < 0 || (! isLooping() && nextPlayPos > getTotalLength())) { return true; } const uint32 endTime = Time::getMillisecondCounter () + timeout; int valid…