[RDD] Latency and xruns [WAS: RD 2.0]
small.net.nz at gmail.com
Sat Jul 10 01:12:42 EDT 2010
Hi Aaron. A small LPFM in Invercargill.
LPFM here btw (for USA readers) is under a Watt, not in the hundreds which
in a dense enough town and high enough antenna, covers about 20,000 people.
We only have a few large cities. We're quite spread out in the South.
However we have the privilege of not needing a tech or application to
operate until higher power is concerned like I think you do in Australia and
At my last high power venture we had RCS. Up to that point I used Simian,
but I've become quite comfortable with Rivendell. Took a while (about a
year) to get the real hang of Linux before I decided to use it full time.
On Sat, Jul 10, 2010 at 1:03 PM, Aaron <aj at rebelmedia.com.au> 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.
> Rivendell-dev mailing list
> Rivendell-dev at lists.rivendellaudio.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rivendell-dev