<br><br>On So, Mai 31, 2015 at 4:19 , jonetsu@teksavvy.com <jonetsu@teksavvy.com> wrote:<br>
<blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">Hello,</div></blockquote><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">
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.</div></blockquote>Any computer program on a PC will receive audio data slightly after the actual event:<br><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;"><a href="http://lists.ardour.org/listinfo.cgi/ardour-users-ardour.org"></a></div></blockquote><div>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.</div><div>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.)</div><div>Likewise there are at least two alternating buffers in memory xthe sound card plays back from.</div><div>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.</div><div><br></div><div>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 </div><div>- recording a bit of audio, </div><div>- calculating the spectrum, </div><div>- manipulating it</div><div>- and transforming the spectrum back to audio data.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Kind regards,</div><div><br></div><div> Gunter.</div>