[Ardour-Users] Audio delay

[Gunter Königsmann]

On So, Mai 31, 2015 at 4:19 , jonetsu at teksavvy.com 
<jonetsu at teksavvy.com> wrote:
> Hello,
> 
>   Using Ardour 4.0.0 I connect both output of a Korg microstation 
> using
> 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 
> it,
> 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 ?
> 
> Cheers.
Any computer program on a PC will receive audio data slightly after the 
actual event:

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.

Kind regards,

     Gunter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ardour.org/pipermail/ardour-users-ardour.org/attachments/20150531/c8506e29/attachment.htm>