[Ardour-Users] Audio delay
gunter at peterpall.de
Sun May 31 08:07:14 PDT 2015
On So, Mai 31, 2015 at 4:19 , jonetsu at teksavvy.com
<jonetsu at teksavvy.com> wrote:
> Using Ardour 4.0.0 I connect both output of a Korg microstation
> qjackctl to the M-1010LT playback inputs. In this case outputs 7 and
> 8 to the first two playback inputs. Then I create a track to record
> choose the Korg MS audio output 7 and 8 and assign them to that track.
> When I play toms, there are single-sound toms.
> Ardour monitoring is set to hardware audio.
> security/limits.d/audio.conf is:
> @audio - rtprio 95
> @audio - memlock unlimited
> #@audio - nice -19
> Kernel is: 3.13.0-24-generic x86_64 (Linux Mint 17).
> When I additionally click on the track's Input button to hear it from
> Ardour, a delay appears, like if the toms had a little to them.
> Definitively not single-sound toms anymore.
> I also experience the same when recording acoustic guitar and wanting
> to hear it through Calf processing by clicking on the track's Input
> button. So much, that I drop it and record only by hearing the guitar
> through the headphones (eg. through the physical headphone shells, not
> the headphone audio where playback occurs) and adjust plug-in
> processing afterwards. Not the same as playing through processing and
> taking real-time advantage of the effects.
> Questions: which one of these are the real hits ? Does it mean
> that what Ardour records is slightly behind the real event ? Is there
> any adjustments to be made in the case of the acoustic guitar to
> benefit from recording using plugin (Calf) processing ?
Any computer program on a PC will receive audio data slightly after the
Every processor can execute one program at a time. It can for example
update the display, calculate the waveforms for displaying an audio
signal at different zoom factors, handle mouse movements or key
presses, save the recorded data in the journal of the filesystem, find
a continouos block of memory on the disk after the recording of a file
has finished to move the data from the journal into to prevent
fragmentation, handle incoming packets from the internet, encode,
filter or decode audio data and so on. Even a modern computer with 4
processors on a single chip does have a complete processor to spare for
handling audio data.
Instead the sound card is given at least two memory regions it can
write to when it records data: Every time it has filled one of these
regions with data it sends the processor a signal that there is urgent
work to be done (to process this data before the other memory region
has been filled, too.)
Likewise there are at least two alternating buffers in memory xthe
sound card plays back from.
The delay between recording and playing back might be small if the
buffers used are small. Ardour therefore asks which buffer sizes it
should use at start-up. Unfortunately a small buffer size means that
every time a buffer is filled with data the CPU hasn't much time to
actually process it before the buffer is needed again. If the CPU is
busy for too long there is no new buffer to record to and data is lost.
This is named buffer underrun.
If audio-processing plug-ins are used things might get even worse: Many
of the more complex tasks in audio manipulation mean that you alter the
spectrum of a signal by actually
- recording a bit of audio,
- calculating the spectrum,
- manipulating it
- and transforming the spectrum back to audio data.
The quality of the sound effect might increase with the size of the bit
of audio so a high-quality effect might need to delay the audio by the
length of the "bit of audio" it has to process in one go. Other effects
like a compressor have to look forward in time to decide if there won't
be any signal above the threshold for the rest of the decay time or
similar - an will have to delay the audio in order to get to know the
future of the audio they output right now.
For time-critical tasks like monitoring music that is played at the
same instant one approach therefore might be to use a analogue-only
monitor to listening to the signal I am recording right now. Another
approach is to limit the delay by using small buffers and only little
post-processing during recording.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Ardour-Users