Then I agree with the poster above, the AudioSource library is probably your best shot. You can implement a class to be an AudioSource and an AudioDeviceCallback.
You should consider your playback device (and it’s AudioIODeviceCallback) to be the main audio thread. Your custom input source AudioSource should be considered just to be like any other thread pushing audio data into the pipeline. If you application is small and your bufferSize is >~128 you might even get away with a CriticalSection as thread safety tool – so this might actually be very easy.
I’d implement your AudioSource to rotate audio data with a fixed size AbstractFifo (e.g. 8192 samples) and overwrite everything that didn’t get picked up by your audio thread. With the AbstractFifo you could just get rid of your CiriticalSection all together. If the numReadyForRead becomes zero, just flush out 0 values, so your hole playback eventually plays silence if e.g. the read audio device is disabled.
You can use the ResamplingAudioSource if that should be necessary. Take note, your AbstractFifo size should orientate on the size of your source sample rate, since that determines the number of samples you need to consume per actual callback from the audio thread.