[arm-allstar] Asterisk internal latency

David McGough kb4fxc at inttek.net
Thu Apr 28 22:40:27 EDT 2022


Patrick,

Three big sources of latency in Asterisk are the 20mS audio frame size,
audio buffering for CODEC transcoding and the jitter-buffer code.

Simpleusb also (minimally) double-buffers the audio frames---meaning that
it doesn't starting processing audio from the linux ALSA layer before
there a 2 frames in the queue.  A similar scenario occurs in the asterisk
conference software and other places.  Every time you double-buffer, this
adds 40mS of latency!

The double-buffering and jitter-buffering attempts to minimize pops and
clicks due to no audio frame being available when it's needed (buffer 
under-run).

When running in allstar duplex=2 mode, the audio frames must traverse all 
these processing layers in Asterisk, hence the delay, which in the best 
case is about 200mS.

The situation with "real-time" audio streaming solutions handle audio
frames very differently from Asterisk.  For example, by using very small
frame sizes, minimal buffering and forward error correction.  The trade
off is considerably higher network bandwidth usage.  Also, AFAIK, most of
the rapid streaming solution don't deal well with larger amount of network
latency and jitter, for example such as found on a 4G network connection.

Note that the notion of a 20mS audio frame is hard-coded into AllStar.  
Changing this would be a massive undertaking.

However, all this being said, there is a solution for audio on local 
repeaters.  Effectively, the soltion is to run in duplex=3 mode and then 
pass the repeater audio around Asterisk altogether.  This is how 
chan_iopipe works.  More about this soon, hopefully.


73, David K4FXC


On Thu, 28 Apr 2022, "Patrick Perdue via ARM-allstar" wrote:

> If using Asterisk in full duplex mode, I.E. duplex=2, there is obviously 
> an inherent delay. What I want to know, however, is why that delay is as 
> high as it is. It seems to have nothing, or very little, to do with the 
> OSS sound driver, as this delay is about the same with a local VoIP 
> device as any of the attached radios using the SimpleUSB channel driver. 
> It just strikes me as odd that I can use a program like Jamulus or 
> Sonobus, and get a high quality, uncompressed stereo PCM or OPUS stream 
> to and from myself across the Atlantic via UDP in quite a lot less time 
> than I can hear myself coming from my own repeater with all the delays 
> from the SimpleUSB channel driver at zero, when network latency isn't 
> even a factor. Yes, I realize that I'm talking about pushing more data 
> across in these cases, and these programs are specifically designed for 
> near zero latency due to their very nature, but it's just interesting to me.
> 
> Is this just the inherent behavior of the old Asterisk 1.4.x core, or is 
> there something else going on here?
> 
> A curious HamVoIP user:
> 
> N2DYI
> 
> _______________________________________________
> 
> ARM-allstar mailing list
> ARM-allstar at hamvoip.org
> http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
> 
> Visit the BBB and RPi2/3/4 web page - http://hamvoip.org
> 



More information about the ARM-allstar mailing list