# Transferring audio events between multiple systems

**URL:** <https://qa.fmod.com/t/transferring-audio-events-between-multiple-systems/18569>\
**Category:** FMOD Engine\
**Tags:** cpp\
**Created:** [March 24, 2022, 7:26am UTC](https://qa.fmod.com/t/transferring-audio-events-between-multiple-systems/18569 "2022-03-24T07:26:56Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![jeff\_fmod](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/jeff_fmod/32/1766_2.png) [@jeff\_fmod](https://qa.fmod.com/u/jeff_fmod)\
**Post date:** [March 31, 2022, 12:31am UTC](https://qa.fmod.com/t/transferring-audio-events-between-multiple-systems/18569/2 "2022-03-31T00:31:42Z")

</div>

> [@Niruva](#):
>
> Is it possible to block these threads, for example, using mutexes and std::condition\_variable?

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`](https://fmod.com/resources/documentation-api?version=2.02&page=core-api-system.html#system_lockdsp) 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](https://qa.fmod.com/t/how-to-connect-two-systems/12091/2) 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?

---

_[View the full topic](https://qa.fmod.com/t/transferring-audio-events-between-multiple-systems/18569)._