Mixer block length vs platforms

Technical question: is the FMOD mixer block length the same between all platforms? Does it change if the buffering length is changed from the API settings?

I’m using a Transceiver that sends from a mixer group back into an event to make a “sound portal”. However there was a flanging drone whenever the portal sound overlapped with the mixer group output, due to the mixer block length delay. I found I could compensate this by placing a delay DSP right after the Transceiver send, to delay the group’s output by one block length so that it matches the phase of the Transceiver event’s output in another mixer bus. (the mixer bus is just for ambience, so the delay does not matter sync wise)

It happens to work with the current setup, but it’s an approximation: I don’t know what the exact block length is, nor if it may be different between platforms or change if buffering etc is changed.

Would authoring a custom “delay signal by exactly 1 block length under any setting” DSP be technically feasible for this purpose?

The block length is configurable via system::setDSPBufferSize, the default does vary between platforms (512-1024).

The transceiver will delay its signal by one mix block, as you have discovered, you could author a delay by one DSP but a simple solution would be to use a send. Each send delays by one mix block.

1 Like

Thank you for the response, and good to know. How should this send be arranged? Should I send the signal to another, new mixer group and mute the original group to delay it? The Send would have to be after the sending Transceiver so that the signal is delayed after it to match phase. So I reckon I need to create a new mixer return for the purpose of delaying and mute the group with a Gain after the Send?

Just tested the solution: the ambience mixer bus sends to a newly created return, and is muted after the send. It matches the delay caused by the Transceiver-to-event, and everything’s working great. Thank you for the tip!