Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
wiki:jack_latency_tests [2010/12/02 11:12] – lgarridowiki:jack_latency_tests [2014/03/18 11:39] (current) – [Interpretation and Analysis] lgarrido
Line 11: Line 11:
 I once watched this guy in an audio forum talk about how he got less latency if he launched jackd from the command-line, and actually thought latency was measured by QJackCtl's DSP Load indicator, so larger audio buffers implied less latency. He was actually a nice guy trying to help, but he was rather confused himself. I once watched this guy in an audio forum talk about how he got less latency if he launched jackd from the command-line, and actually thought latency was measured by QJackCtl's DSP Load indicator, so larger audio buffers implied less latency. He was actually a nice guy trying to help, but he was rather confused himself.
  
-So, leaving aside buzzwords, hype and urban legends, what is actually latency? [[http://en.wikipedia.org/wiki/Latency_%28audio%29|Latency]] is how you call the reaction time of a system to a stimulus.+So, leaving aside buzzwords, hype and urban legends, what is actually latency? [[http://en.wikipedia.org/wiki/Latency_%28audio%29|Latency]] is how you call **the reaction time of a system to a certain stimulus**.
  
 In the audio world, latency is the time elapsed between an action that produces sound and the actual perception of that sound by a listener. In the audio world, latency is the time elapsed between an action that produces sound and the actual perception of that sound by a listener.
Line 21: Line 21:
 There are many factors that contribute to the total latency of a given system. Some of the more relevant are: There are many factors that contribute to the total latency of a given system. Some of the more relevant are:
  
-  * Sound propagation in the air: since it is a mechanical perturbation in a fluid, sound travels at comparatively slow [[http://en.wikipedia.org/wiki/Speed_of_sound|speed]]: about 340 m/s. Some interesting consequences:+  * **Sound propagation through the air**: since it is a mechanical perturbation in a fluid, sound travels at comparatively slow [[http://en.wikipedia.org/wiki/Speed_of_sound|speed]]: about 340 m/s. Some interesting consequences:
     * Your acoustic guitar or piano has a latency of about 1-2 ms, due to the propagation of the sound between your instrument and your ear .     * Your acoustic guitar or piano has a latency of about 1-2 ms, due to the propagation of the sound between your instrument and your ear .
     * At a large concert venue if you are far away from the stage the sound will travel faster through the path "singer-mic-nearest loudspeaker-your ear" than through the "singer-air-your ear" one, so you'll hear the real sound as an echo of the amplified one. Relativistic time-paradox or what?     * At a large concert venue if you are far away from the stage the sound will travel faster through the path "singer-mic-nearest loudspeaker-your ear" than through the "singer-air-your ear" one, so you'll hear the real sound as an echo of the amplified one. Relativistic time-paradox or what?
-  * Digital-to-Analog and Analog-to-Digital conversion. Electric signals travel quite fast, so their propagation time is negligible in this context, but the conversions between the analog and digital domain take a comparatively long time to perform, so their contribution to the total latency may be considerable. +  * **Digital-to-Analog and Analog-to-Digital conversion**: electric signals travel quite fast, so their propagation time is negligible in this context, but the conversions between the analog and digital domain take a comparatively long time to perform, so their contribution to the total latency may be considerable. Fast converters are, for instance, one of the factors that distinguishes a quality audio interface from a cheap one, along with other features like low noise, low distortion, etc. 
-  * Digital Signal Processing. Digital processors tend to process audio in chunks, and the size of that chunk depends on the needs of the algorithm and performance/cost considerations. This is the main cause of latency when you use a computer and one you can try to predict and optimize. +  * **Digital Signal Processing**: digital processors tend to process audio in chunks, and the size of that chunk depends on the needs of the algorithm and performance/cost considerations. This is usually the main cause of latency when you use a computer and one you can try to predict and optimize. 
-  * Computer I/O Architecture. A computer is a general purpose processor, not a digital audio processor. This means our audio data has to jump a lot of fences in his path from the outside to the CPU and back, contending in the process with some other parts of the system vying for the same resources (CPU time, bus bandwidth, etc.) Thanks to the combined efforts of kernel, audio driver and jackd smart developers you are in position to tune your system a bit more towards the digital audio processing task, but don't expect miracles. Remember you can use your computer also to write documents, surf the net, save some lemmings... Polyvalence comes at a cost.+  * **Computer I/O Architecture**: a computer is a general purpose processor, not a digital audio processor. This means our audio data has to jump a lot of fences in his path from the outside to the CPU and back, contending in the process with some other parts of the system vying for the same resources (CPU time, bus bandwidth, etc.) Thanks to the combined efforts of kernel, audio driver and jackd smart developers you are in position to tune your system a bit more towards the digital audio processing task, but don't expect miracles. Remember you can use your computer also to write documents, surf the net, save some lemmings... Polyvalence comes at a cost.
  
 ===== Does latency really, really matter? ===== ===== Does latency really, really matter? =====
  
-Less than most people think, in our opinion. There are only a few use-cases where is important for latency to be very low, because they require very quick response from the computer. Some examples that come quickly to mind are:+Less than most people think, in our opinion. There are only some situations where a very low latency is really important, because they require very quick response from the computer. Some examples that come quickly to mind are:
  
-  * Playing virtual instruments. A large delay between the pressing of the keys and the sound the instrument produces will throw-off the timing of most instrumentalists (save if they are church organists, whom we believe are awesome latency-compensation organic systems.) +  * **Playing virtual instruments**: a large delay between the pressing of the keys and the sound the instrument produces will throw-off the timing of most instrumentalists (save if they are church organists, whom we believe are awesome latency-compensation organic systems.) 
-  * Software audio monitoring. If a singer is hearing her own voice through two different paths, her head bones and headphones, large latencies can be disturbing. +  * **Software audio monitoring**: if a singer is hearing her own voice through two different paths, her head bones and headphones, large latencies can be disturbing. 
-  * Live-effects. Precise synchronization may be important if you trigger manually sound effects like delays. +  * **Live-effects**: This case is similar to playing virtual instruments: instead of virtual-instruments/sythensizers it is about real-instruments and and effects processing. Low latency is important when using the computer as effect-rack (e.g. guitar effects) - also precise synchronization may be important if you trigger manually sound effects like delays. 
-  * Live-mixing (case example needed).+  * **Live-mixing**: Some sound engineers use a computer for mixing live performances. Basically that is a combination of the above: monitoring on stage, effect-processing and EQ. It is actually more tricky since one not only wants low latency (audio should not lag too much behind the performance) but exact low-latency (minimal jitter) for delay-lines between speaker in front and back.
  
-In most other cases (such as playback, recording, overdubbing, etc.) latency is not important or can be compensated for.+In many other cases (such as playback, recording, overdubbing, etc.) latency is not that important or can be compensated for.
  
-In the end, it is not that much the size, but how well you use it.+At the end of the day, it is not so much its size, but how well you use it.
  
 ===== The smaller the better? ===== ===== The smaller the better? =====
 TODO TODO
-===== Capture latency and playback latency ===== +===== Capture latency, playback latency, roundtrip latency, huh? ===== 
-TODO+ 
 +When you are talking about latencies it is important to be precise about where and how are they measured. 
 + 
 +At the end of the day, what really matters is the latency perceived by the person who is using the system. But this latency is itself comprised of smaller, partial latencies. The ones that usually contribute more to the total are usually: 
 + 
 +  * **Air propagation latency**. 
 +  * **Converter latency**. 
 +  * **Processing latency**. 
 +  * **Digital I/O latency**. 
 + 
 +There is not much we can do about the first two other than using headphones or sitting near the loudspeaker and buying quality gear. 
 + 
 +Processing latency is usually divided into capture latency and playback latency: 
 + 
 +  * **Capture latency**: the time necessary for the digitized audio to be available for digital processing. Usually it is one audio period. 
 + 
 +  * **Playback latency**: the time necessary for the digitized audio to be processed and delivered out of the processing chain. At best it is one audio period. 
 + 
 +But this division is an implementation detail of no great interest for the user, since one has no control over it. What really matters is the combination of both, what we could call the **processing roundtrip latency**: the time necessary for a certain audio event to be captured, processed and played back. 
 + 
 +It is important to note that **processing latency in a jackd is a matter of choice**: we can lower it as much as we want, within the limits imposed by the audio driver. But the lower it is, the more likely our system will fail to meet it, so the dreaded xrun will make its appearance more often, leaving its merry trail of clicks, pops and crackles. 
 + 
 +The digital I/O latency is usually negligible for integrated or PCI audio devices but, as we'll see later, it can be important for USB or FireWire interfaces. 
 ===== Measuring roundtrip latency with jack_delay ===== ===== Measuring roundtrip latency with jack_delay =====
-TODO+ 
 +[[http://kokkinizita.linuxaudio.org/linuxaudio/|jack_delay]] is an utility developed by Linux DSP guru Fons Adriaensen to measure the roundtrip latency of a closed loop audio chain. 
 + 
 +jack_delay works by emitting some rather annoying tones, capturing them again after a roundtrip through the whole chain and measuring the difference in phase so it can estimate with great accuracy how long has the whole process taken. This is no theoretical estimation, jack_delay is a measuring tool that will give you the real deal. 
 + 
 +You can close the loop on a number of ways: 
 + 
 +  * Putting a speaker close to a microphone. This is rarely done, as air propagation latency is well known so there is no need to measure it. 
 +  * Connecting the output of your audio interface to its input using a patch cable. This can be an analog or a digital loop, depending on the nature of the input/output you use. A digital loop won't factor in the converters latency. 
 + 
 +If you want to measure the latency of a cheap, integrated sound card that only has line-output and mic-input you cannot close the loop with a simple patch cable: both connectors may be mechanically compatible, but electrically they are not designed to work together, so attempting to connect them may harm your audio interface. If you are curious, anyway, you can [[http://web.archive.org/web/20060410075235/http://www.tkk.fi/Misc/Electronics/circuits/line_to_mic.html|build a pad]] with a couple of resistors to adapt their impedances. Here's how we did it, but we take no responsibility for any harm your equipment might suffer. DO IT AT YOUR OWN RISK! 
 + 
 +{{:wiki:line2mic-unplugged.jpg|}} 
 + 
 +{{:wiki:line2mic-plugged.jpg|}} 
 + 
 +Some notes: 
 +  * The black plug goes into the mic outlet, so the 100 ohm resistor is in parallel with it. 
 +  * The mic ring carries a DC voltage to polarize electret microphones, so leave that wire open. 
 + 
 +Once you have closed the loop you have to: 
 +  - Launch jackd with the configuration you want to test. 
 +  - Launch jack_delay. 
 +  - Make the appropriate connections between your jack ports so the loop is closed. 
 +  - Adjust the playback and capture levels in your mixer. 
 +   
 +If everything goes according to plan, jack_delay should start to emit messages indicating the roundtrip delay measured both in milliseconds and in audio frames (there are SR audio frames in one second, where SR is the sample rate.) 
 + 
 +<code> 
 +$ jack_delay  
 +capture latency  = 1024 
 +playback_latency = 2048 
 +Signal below threshold... 
 +Signal below threshold... 
 +Signal below threshold... 
 +  3104.419 frames     64.675 ms ?? Inv 
 +  3104.416 frames     64.675 ms ?? Inv 
 +  3104.415 frames     64.675 ms ?? Inv 
 +  3104.417 frames     64.675 ms ?? Inv 
 +</code> 
 ===== Adjusting latency ===== ===== Adjusting latency =====
 TODO TODO
Line 52: Line 115:
 The [[http://jackaudio.org|JACK]] Audio Connection Kit has a few parameters to configure the latency. However the settings are constrained by hardware (audio-device, CPU and bus-speed). Lower latencies increase the load on the computer-system (it needs to process the audio in smaller chunks which arrive much more frequently). If the system can not keep up: an //x-run// (short for buffer over-run and buffer under-run) occurs which usually results in audible clicks or dropouts. The [[http://jackaudio.org|JACK]] Audio Connection Kit has a few parameters to configure the latency. However the settings are constrained by hardware (audio-device, CPU and bus-speed). Lower latencies increase the load on the computer-system (it needs to process the audio in smaller chunks which arrive much more frequently). If the system can not keep up: an //x-run// (short for buffer over-run and buffer under-run) occurs which usually results in audible clicks or dropouts.
  
-Low-latency is not always a feature you want to have. It comes with a couple of drawbacks: the most prominent is increased power-consumption because the CPS needs to process many small chunks of audio-data, it is constantly active and can not enter power-saving mode. Furthermore, if more than one application (sound-processor) is involved in processing the sound, the operating system performs a context-switch to run each of these for each audio-cycle which results in a much higher system-load and an increased chance of x-runs.+Low-latency is not always a feature you want to have. It comes with a couple of drawbacks: the most prominent is increased power-consumption because the CPU needs to process many small chunks of audio-data, it is constantly active and can not enter power-saving mode. Furthermore, if more than one application (sound-processor) is involved in processing the sound, the operating system performs a context-switch to run each of these for each audio-cycle which results in a much higher system-load and an increased chance of x-runs.
  
 Stable low-latency (≤10ms) on GNU/Linux can usually only be achieved by running [[https://rt.wiki.kernel.org/|realtime-kernel]] (insert links to ''rtirq'' and setup/config info here). Stable low-latency (≤10ms) on GNU/Linux can usually only be achieved by running [[https://rt.wiki.kernel.org/|realtime-kernel]] (insert links to ''rtirq'' and setup/config info here).
Line 92: Line 155:
   - It seems that for USB devices JACK //secretly// adds an additional period latency, but at most 1024 frames. This phenomena is not present with PCI devices.   - It seems that for USB devices JACK //secretly// adds an additional period latency, but at most 1024 frames. This phenomena is not present with PCI devices.
   - The latency reported by JACK is inconsistent.   - The latency reported by JACK is inconsistent.
 +
 +The first issue was explained by ALSA developer Clemens Ladisch in [[http://jack-audio.10948.n7.nabble.com/Differences-in-latency-between-USB-and-internal-audio-interfaces-td9071.html|this thread in jack-devel]]. The USB driver adds an extra period or a 24 ms buffer, whichever is smaller.
  
 Looking closer at these two issues: Looking closer at these two issues:
Line 119: Line 184:
  
 Alas, total latency measurement can not tell which it is. Alas, total latency measurement can not tell which it is.
- 
 ===== References ===== ===== References =====
  
-  * [[http://www.kokkinizita.net/linuxaudio/|jack_delay]]+  * [[http://kokkinizita.linuxaudio.org/linuxaudio/|jack_delay]]
   * [[http://linuxaudio.org/mailarchive/lau/2009/4/2/153739|Thread on LAU - using jdelay]]   * [[http://linuxaudio.org/mailarchive/lau/2009/4/2/153739|Thread on LAU - using jdelay]]
   * [[http://linuxaudio.org/mailarchive/lau/2009/4/2/153759|Fons UA-5 measurement]]   * [[http://linuxaudio.org/mailarchive/lau/2009/4/2/153759|Fons UA-5 measurement]]
 +  * A script to acquire the data using ''jack_delay'' can the found at ''%%git://rg42.org/latentor%%'' or directly: [[http://rg42.org/gitweb/?p=latentor.git;a=snapshot;sf=tgz|latentor.tgz]].
  
 ===== Raw data ===== ===== Raw data =====
wiki/jack_latency_tests.1291284721.txt.gz · Last modified: 2010/12/02 11:12 by lgarrido