[RDD] Latency and xruns [WAS: RD 2.0]

Fred Gleason fredg at paravelsystems.com
Thu Jul 8 10:56:40 EDT 2010

On Thursday 08 July 2010 09:51:22 am you wrote:
> How the parameter PeriodQuantity can affect the latency and the xruns? What
> it does?

That value sets the buffer size (in PCM frames) which the DSP engine inside 
caed(8) will use when processing audio (both capture and playout).  The 
larger the buffer size, the longer the latency.  Think of it in terms of 
granularity -- smaller buffers mean finer-grained control over things like 
playout starts.  There's a danger with smaller buffers though -- as the size 
shrinks, the number of times per second which the code needs to execute that 
processing increases.  All OSes have a limit beyond which they will not be 
able to schedule that processing reliably.  When that happens, the result is 
xruns -- the system can't keep up, so data is lost, resulting in audible 
clicks, pops and other nasty artifacts.

The distinctive feature of the 'hard' realtime OSes that Cowboy likes to talk 
about is that they offer a *guarantee* that a certain process can be 
scheduled within a certain period of time.  It's not necessarily that it's 
*fast*, but rather the fact that it's *predictable* ('deterministic' is the 
buzzword used by software engineers) that makes a hard RTOS so valuable for 
implementing certain types of solutions.

Linux is not a hard RTOS (neither is Windows, OS X nor any other 'general 
purpose' OS).  The best it can do is 'soft' RT, which is basically a 'best 
effort' sort of thing; even that requires using a preemptive kernel and 
careful system tuning.  This is why ASI cards can deliver significantly 
better performance here: each of those cards actually has a separate computer 
processor onboard, running a true hard RTOS, that is totally dedicated to 
processing audio.  As a result, the card's internal DSP core can operate with 
very small mix buffers, hence giving very good (low) latency.  That's also 
one of the reasons why those cards are so expensive.

In the ALSA/JACK realm, we're not so fortunate; we end up having to emulate 
all that using the main computer CPU.  Linux is not hard RT; that means 
larger buffers, hence more latency.

The bottom line on all of this is something I've said many times over the 
years: the JACK/ALSA drivers can be very useful for many roles in Rivendell, 
but for an RDAirPlay system that you're putting on the air, buy an ASI card.  
You won't regret it.


| Frederick F. Gleason, Jr. |               Chief Developer               |
|                           |               Paravel Systems               |
| Like the ski resort of girls looking for husbands and husbands looking  |
| for girls, the situation is not as symmetrical as it might seem.        |
|                                        -- Alan McKay                    |

More information about the Rivendell-dev mailing list