[2024-feb-29] Sad news: Eric Layton aka Nocturnal Slacker aka vtel57 passed away on Feb 26th, shortly after hospitalization. He was one of our Wiki's most prominent admins. He will be missed.
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revisionLast revisionBoth sides next revision | ||
howtos:multimedia:digital_audio_workstation:compensating_latency [2020/08/05 12:23 (UTC)] – created placeholder alienbob | howtos:multimedia:digital_audio_workstation:compensating_latency [2020/08/05 21:03 (UTC)] – [An Alternative Test (and Visualizing Latency)] 0xbf | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | <!-- Add your text below. We strongly advise to start with a Headline (see button bar above). --> | + | ====== |
- | ====== | + | |
- | Coming soon... | + | ===== Overview of Latency and its Sources ===== |
+ | Audio data is moved in " | ||
+ | |||
+ | |||
+ | //E.g. A Frames/ | ||
+ | 512 x 3 = 1536 Frames/ | ||
+ | If the sample rate is set at 48000Hz, then the buffer fills in:\\ | ||
+ | 1536/48000 = 0.032 seconds, or 32 milliseconds// | ||
+ | |||
+ | \\ | ||
+ | |||
+ | |||
+ | Larger buffers end up being audible as delay when playing a monitored instrument. For example, playing a chord on a MIDI piano and hearing it after a delay in headphones. The buffer settings can be reduced to find an acceptable amount of delay for playing, at trade-off of risk of xruns. Alternatively the buffer can be increased to allow more latency which gives more stable audio performance.\\ | ||
+ | |||
+ | |||
+ | //**xruns** are audible glitches or pops that occur when the computer can't keep up with the task of filling up the buffer with samples. They occur more easily at lower buffer sizes and/or higher sampling rates, since it is more work for the CPU to write these smaller buffers at a quicker rate.// | ||
+ | |||
+ | \\ | ||
+ | |||
+ | |||
+ | In any case, the audio server knows how it is configured and can compensate for the known delay of the buffer size and sample rate. This compensation is done by delaying when recorded tracks are written to file, keeping all the timing of a multi-track recordings in sync.\\ | ||
+ | |||
+ | |||
+ | However, there is still additional delay from the audio interface hardware (ADC's and DAC's) and remaining audio chain. These delays can be measured and input to the audio server to completely compensate signal latency. Several ways to achieve this will be outlined below. | ||
+ | |||
+ | ===== Using QJackCtl and jack_iodelay ===== | ||
+ | |||
+ | Slackware Live DAW come with QJackCtl to manage the jackd server, and starts this automatically at boot/login. This can be configured else-wise, but to work with the stock setup you can use " | ||
+ | |||
+ | |||
+ | Once QJackCtl is running the JACK server, open up a terminal and run " | ||
+ | |||
+ | |||
+ | {{.images: | ||
+ | |||
+ | Open up the connection graph in QJackCtl and you will find a " | ||
+ | |||
+ | |||
+ | {{.images: | ||
+ | |||
+ | The last step is to connect the physical output back to the physical input that jack_iodelay is using. Also don't use an output with speakers, the program uses a series of tones to measure latency and you probably don't want to hear them.\\ | ||
+ | |||
+ | |||
+ | {{.images: | ||
+ | |||
+ | After all connections are made, jack_iodelay will report the full loop latency, in milliseconds, | ||
+ | |||
+ | |||
+ | {{.images: | ||
+ | |||
+ | Quit jack_iodelay (Ctrl+c), stop the server in QJackCtl, and enter the "Setup menu". On the advanced tab there are entry spots for Input and Output latency. Enter the values from jack_iodelay here, then restart the server.\\ | ||
+ | |||
+ | |||
+ | {{.images: | ||
+ | |||
+ | Now the jack server will be able to report the latency of its hardware ports as well, allowing programs to properly sync up overdubbed tracks when recording. | ||
+ | |||
+ | ===== Using Ardour ===== | ||
+ | |||
+ | Ardour comes with latency compensating tools built into its GUI (which are a little easier to use than first method). Note that Slackware Live DAW comes pre-configured to automatically start jackd/ | ||
+ | |||
+ | |||
+ | {{.images: | ||
+ | |||
+ | Note that Ardour can use ALSA directly, or start its own JACK instance as well. In any case, select your audio interface for the Input and Output device and choose an acceptable sample rate, buffer size, and period size for your audio work. Then wire a loop back cable from an output to an input on your interface (the same as done in the first method). Once the hardware interface is looped, you can use the " | ||
+ | |||
+ | {{.images: | ||
+ | |||
+ | Select the appropriate ports that are looped, and click measure. The latency is measured, and the results are derived, the same as the first method (it is in fact running jack_delay in the back-end here).\\ | ||
+ | |||
+ | |||
+ | You can set the latency compensation by clicking "Use Results", | ||
+ | |||
+ | ===== An Alternative Test (and Visualizing Latency) ===== | ||
+ | |||
+ | Both of the latency compensation techniques discussed in this article have used a loop back connection from the audio interface to send a signal through an output port and back to an input port. This return signal is delayed by the hardware latency, which can then be measured. You can also record this latency and see it for yourself by using a click track.\\ | ||
+ | |||
+ | |||
+ | This example will use Ardour to show how to achieve this, since it its the primary DAW program that comes with Slackware Live DAW. Similar steps could be carried out with other recording programs.\\ | ||
+ | |||
+ | |||
+ | Start a new recording session, without any latency compensation in place. Also loop an output back to an input on your audio interface, with the same technique as in the other latency compensating methods above.\\ | ||
+ | |||
+ | |||
+ | Create a new audio track to record the click. Disconnect the input of this track. Then open up the "Audio Connections" | ||
+ | |||
+ | {{.images: | ||
+ | |||
+ | Then record a few seconds onto the track (with the metronome enabled). | ||
+ | |||
+ | {{.images: | ||
+ | |||
+ | Zoom into a single impulse (Ctrl+Scroll-wheel). You will see that the impulse starts later than the grid-line, which is where the red play-head is in the image below. The metronome is sounded at each quarter note on the grid, but doesn' | ||
+ | |||
+ | |||
+ | {{.images: | ||
+ | |||
+ | This works out to 511/48000 = 10.64 milliseconds of latency.\\ | ||
+ | |||
+ | |||
+ | Stop the audio server and repeat the audio setup, but this time add the latency compensation. Once that is done, record another section of clicks, and zoom in again. | ||
+ | |||
+ | {{.images: | ||
+ | |||
+ | Now the impulse should line up on the grid line, or very close. This is because the audio server has compensated for the hardware delay, allowing the timing to be precise. In my case here my " | ||
+ | |||
+ | ====== References ====== | ||
+ | |||
+ | [[https:// | ||
+ | [[https:// | ||
+ | [[https:// | ||
====== Sources ====== | ====== Sources ====== | ||
- | <!-- If you are copying information from another source, then specify that source --> | + | |
- | <!-- * Original source: [[http:// | + | * Originally written by [[wiki: |
- | <!-- Authors are allowed to give credit to themselves! --> | + | * Converted from latex sources using pandoc and sed by [[wiki: |
- | < | + | |
- | < | + | |
<!-- Please do not modify anything below, except adding new tags.--> | <!-- Please do not modify anything below, except adding new tags.--> | ||
<!-- You must remove the tag-word " | <!-- You must remove the tag-word " | ||
- | {{tag> | + | {{tag> |