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

Rob Landry 41001140 at interpring.com
Sat Jul 10 09:01:04 EDT 2010

Do "Next Timed Start" and "Next Stop" reflect these delays? Somehow I 
don't think they do, because I'm looking at WCRI's rdairplay screen right 
now and it's showing a Next Stop time of 23:36:17, which would imply it's 
going to end 24 minutes early. I can almost guarantee it won't.


On Sat, 10 Jul 2010, Aaron wrote:

> Thanks Fred for the explanation and pointers in reducing/optimising Alsa
> delay in RD 1.x
> Our commercials in RCS have segue markers at exactly 15/30/60 seconds,
> and where needed are time stretched via Pro Tools first.  Gavin, glad
> you raised the "moving markers" issue, I'd noticed that but forgotten
> about it.  Yes, as you mentioned hopefully that's fixed in 2.0 as well,
> markers should indeed stay exactly where they are put.  Gavin, what's
> your station in NZ?
> Interesting discussion on how the segue delay can not be eliminated but
> may be able to be reduced to say 5ms or so.  Fred, I wonder though why
> it can't be reduced for most events further, by pre-rolling the audio?
> The first audio event in a sequence (operator started, or by external
> trigger etc) may take the 5-10ms to fire, but what about all the events
> following it?
> For example, assume a system/audio device combo has an average 10ms
> segue delay time.  If Song A is playing and has a SEGUE START marker at
> 30,000ms, then the RD audio engine could be coded to just pre-empt the
> SEGUE START marker by 10ms, and start Song B when the Song A position
> reaches 29,990 ms. Perhaps a fixed SEGUE START pre-roll in ms could be
> set in RDAdmin independently for each audio device, with an installation
> default of 0ms for those that don't need or want to use the feature ?
> This would effectively come much closer to eliminating segue delay,
> assuming the delay in starting a track is relatively constant.
> I agree, reducing the segue delay to 5-10ms would likely not be
> noticeable on air between adjacent events.. That would solve that aspect
> of the problem.   But there is also still the cumulative effect to
> consider, as mentioned by Rob.  A network break with 10 events in it
> could still be 100ms late at the end of the break, which is not good..
> We time and automate up to 4 four hour long blocks at night, which with
> 200+ events, could put us up to 2.4 seconds late at the end of the block
> - a train wreck in practice.  And that's assuming segue times were down
> to 10ms, which as you mentioned may not be possible for Axia AoIP etc.
> Is this a feasible solution?
> Thanks all.
> Aaron
> _______________________________________________
> Rivendell-dev mailing list
> Rivendell-dev at lists.rivendellaudio.org
> http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev

More information about the Rivendell-dev mailing list