I also don’t think, that this is a good advice! Avoid system calls all together when handling with realtime trait is one of the most essential tips anyone will ever give you when working with the audio threads.
I also don’t grasp the concept on what FIFO latency you are referring to. Stuff gets copied by the input source, and as soon as the copy operation is done, the output source may grab it. I wouldn’t speak of latency neither with a FIFO nor with mutex. When nothing is available in the FIFO when the output wants to play audio data, then nothing is being played or when the input is still writing and holding the mutex lock while the output would like to access the data, the output waits for the input to finish. I don’t see any actually defined latency being involved.
In addition, a FIFO is a perfectly good example of handling shared memory. The JUCE AbstractFifo actually makes the perfect case for that. The class itself does even hold the actual data being stored or read. It just tells the callees which regions of the data is save to be read from and written to, all while ensuring there will be no race conditions, exactly the same the mutex would be doing expect it is lock free.
And then finally: even when using mutexex, you’d still be better off with a FIFO structure nonetheless (even when it is not lock free). A FIFO Queue is an excellent choice for what we are trying to achieve here. There is stuff coming in at unknown times, and there should stuff be flushed at unknown times in uncertain intervals. We want to make sure what comes in first, is flushed first and we’d like a little bit of buffer, when input was called ahead of time, or output was not picked up caused by a lag of some sort. Making it a ring buffer would also make total sense, assuring that the input is allowed to overwrite the most outdated data when the output is behind by a lot of calls.
There is a similar discussion going on here: Using different audio devices at the same time? - #4 by Rincewind