[Fwd: Re: [Ardour-users] WAV files, xruns]
eviltwin69 at cableone.net
Sat Feb 21 11:05:09 PST 2004
Oops, I meant to post this to the list as well.
From: Jan Depner <eviltwin69 at cableone.net>
To: Nathan Funk <nathanfunk at shaw.ca>
Subject: Re: [Ardour-users] WAV files, xruns
Date: 21 Feb 2004 11:37:42 -0600
There is always a period * sample size latency between when you record
something and when you can hear it played back. If you don't have a
card that has hardware monitoring (onboard mixer) this is a PITA. You
usually have to keep the sample size small so you can record and monitor
at somewhere near realtime (so it doesn't drive you nuts as noted
earlier). The latency that *really* matters is the system latency.
This is the amount of time that it takes for your system to respond to
an interrupt from the sound card (even your sound card has it's own
latency). System latency varies depending on what is going on. This is
why we use the low latency and preemptible kernel patches and try to
minimize the number of other processes running when recording. If your
system can't service an interrupt from the sound card in a reasonable
amount of time (say, because your video card is hogging the PCI bus) you
get an under or over run (xrun). Ardour will write the data in it's
buffers to disk when it has filled a buffer (period * sample rate).
Disk I/O has it's own overhead associated with it and it is easier to
write larger buffers to disk than small ones (thus reducing xruns).
That's the 5 cent tour. It's not completely accurate but it covers the
On Sat, 2004-02-21 at 03:57, Nathan Funk wrote:
> Just as an aside to this thread - It appears that many newbies
> (including myself) get the wrong idea about what latency is all about.
> It took me a while to figure out that this latency everyone is talking
> about has no (or minimal) effect on whether tracks will be in sync with
> each other when recording one after the other.
> AsJan just stated - Ardour (or Jack) compensate for the latency caused
> by buffering. Say you recorded one track already. You want to record
> another track on top of that. Your latency is 50ms. While recording, it
> takes (at least?) 50ms before a buffer is filled and passed on to
> Ardour. BUT Ardour (or Jack) knows about this, and aligns the new track
> with the old track _very precisely_. There is no 50ms delay on the
> second track.
> There is a lot of emphasis put on reducing latency, but it appears that
> for casual recorders it might not be too important. It seems that some
> of the material available tends to mislead newbies into believing that
> latency <10ms is necessary for recording anything.
> Maybe I'm wrong about every little thing I'm talking about
> Maybe I'm wrong, but just maybe, maybe I'm right
> Jan Depner wrote:
> >On Sat, 2004-02-21 at 07:35, Robert Jonsson wrote:
> >>This is impossible to answer, technically the delay imposed does not matter.
> >>The recordings you make will not "wander", the 11ms are fixed. I record quite
> >>oftenly at 512*2, though 256*2 is more comfortable.
> >>I'm not sure if ardour supports latency compensation (yet) during recording,
> >>if it does then I guess it's possible that subsequent recordings are not
> >>correctly aligned to the former?
> > Ardour does do latency compensation (or maybe it's JACK - anyway, it
> >>What happens that might be a problem is if you are listening to your own
> >>"take" through ardour, while you are playing. Then what you are listening to
> >>will be delayed 11ms + 11ms which definitely is noticeable and might be a
> > Just buy a card with hardware monitoring (any of the ice1712/envy24
> >cards - 1010, 1010LT, DSP-2000 C-Port, EWS88MT, Delta 66, Delta 44...).
> >Then you can set to 2048 when recording and get no delay in hearing what
> >you are recording/playing versus what Ardour is playing. I do this all
> >the time with my DSP2000.
> >ardour-users-ardour.org mailing list
> >ardour-users at lists.ardour.org
More information about the Ardour-Users