High latency in "Passthrough" example program

Max_

Hello,

I have observed that the latency in the "passthrough" example is unexpectedly high. With audio frames set to 256 (running at 44.1kHz), I am measuring a delay of approximately 15.5ms (742 samples with a 48kHz recording) when compared to an analog loopback. I had initially anticipated a latency close to 550 samples at 44.1kHz, based on the information I found in the "An Environment for Submillisecond-Latency Audio and Sensor Processing on BeagleBone Black". According to the paper, the theoretical round-trip latency should be 2 * buffer size + 17 + 21 = 550 samples, with 17 and 21 samples introduced by audio codecs. However, my measurements show 742 samples (recorded at 48kHz), which translates to approximately 682 samples at 44.1kHz.

Now, I'm trying to understand what could be causing this additional latency. Any help or suggestions would be greatly appreciated!

giuliomoro

The highest "hardware" block size maxHwBlockSize is:

128 samples per block for Bela Rev B or BelaMini
64 samples per block for Bela RevC, BelaMini + Multichannel audio expandr, or CTAG FACE
32 samples per block for CTAG BEAST

When going above the "hardware" block size, an extra layer of buffering is added, bringing total roundtrip latency to maxHwBlockSize + 2*blockSize (I think), where blockSize is the block size you set in the project settings.

Add to that the 38 samples from the codec loopback and two or three samples from the serialiser and I think you get very close to your observed value. Btw, I would expect the delay in sample to be fixed regardless of the sampling rate.

Max_

Great, thank you very much for your fast replay! :-D

I've done a quick "passthrough" test with my Rev B Bela, where the results reflect to your reply. Measured at 44.1 kHz

block size = 64, measured samples = 170, 2 * 64 + 17 + 21 = 166
block size = 128, measured samples = 298, 2 * 128 + 17 + 21 = 294
block size = 256, measured samples = 681, 2 * 256 + 17 + 21 = 550, 550 + 128 (maxHwBlockSize) = 678

So, the measured latency is 3-4 sample points higher than the calculated one. Perfect! :-D Thank you so much for clarifying!

Could you point me to the parts of the Bela core's code, where maxHwBlockSize is defined and where an extra layer of buffering is added? I could not find it yet.

giuliomoro

Max_ e, where maxHwBlockSize is defined

it's not defined as such, but it's used to compute the gFifoFactor here: https://github.com/BelaPlatform/Bela/blob/4e11f70883c4e0ad635c5c31d2167e58f64f8775/core/RTAudio.cpp#L626-L650

If gFifoFactor > 1, then a BelaContextFifo is created (gBcf) and it is used to communicate between the fifoRender() callback (which runs at the hw block size) and the user-defined render() callback (which is stored in settings->render): https://github.com/BelaPlatform/Bela/blob/4e11f70883c4e0ad635c5c31d2167e58f64f8775/core/RTAudio.cpp#L740-L748

Max_

Great, thank you very much! :-D