Transferring audio events between multiple systems

Hello!

I implement Dualsense gamepad support for Windows with an additional FMOD::System object that works with the gamepad driver. There was a need to transfer sound events from the main system to the additional one.
For example, we have system “A” in which the main sound is processed and we have system “B” which is responsible for the gamepad. I need to send a sound event from system “A” to system “B”. Is there a way to do this efficiently?

For now, I’m using a two DSP implementation using an intermediate buffer. The first DSP is created in system “A” and is tied to a special bus. Vibrations created in FMOD Studio are sent to this bus. The second one is created in system “B”. The first DSP, when FMOD_DSP_READ_CALLBACK is called, reads data from the input buffer and writes to the intermediate buffer. The second DSP, when calling FMOD_DSP_READ_CALLBACK, reads data from the intermediate buffer and writes to the output buffer. This works, but there is a significant delay. The delay is approximately ~ 60…100 ms. The latency can be reduced with System::setDSPBufferSize, but this results in a race condition because the DSP callbacks run on different “FMOD mixer threads”. Is there a way to reduce latency with this implementation? Is it possible to block these threads, for example, using mutexes and std::condition_variable?

In diagram form, it looks something like this:

Alternatively, i can write an output plugin and use FMOD::System::setOutputByPlugin to override how the device works, but is there an easier way?

Usually you want to avoid locks in real-time audio and we don’t provide any way of blocking the mixer thread. As far as the latency with your current implementation goes, how is this shared buffer synchronized between the two system’s dsp callbacks? Are there any locks in there or is the shared buffer using a circular-buffer / some lock-free alternative?
EDIT: Amending my answer, you can block the mixer thread with System::lockDSP/System::unlockDSP but that probably won’t help with your latency issues. Syncing two systems can be problematic due to clock drift if the two devices separate hardware interfaces. In previous discussions there was a suggestion to delay the output buffer by one buffer to compensate for latency- this might be worth a shot in your case?