| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| wiki:jack_latency_tests [2010/12/03 01:39] – Measuring with jack_delay lgarrido | wiki:jack_latency_tests [2014/03/18 11:39] (current) – [Interpretation and Analysis] lgarrido |
|---|
| * **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**: similar to software monitoring. 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-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**: Is a variant of the above. Some sound engineers use a computer for mixing live performances. | * **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 many other cases (such as playback, recording, overdubbing, etc.) latency is not that 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. |
| ===== Measuring roundtrip latency with jack_delay ===== | ===== Measuring roundtrip latency with jack_delay ===== |
| |
| [[http://www.kokkinizita.net/linuxaudio/|jack_delay]] is an utility developed by Linux DSP guru Fons Adriaensen to measure the roundtrip latency of a closed loop audio chain. | [[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. | 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. |
| * 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. | * 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://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! | 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-unplugged.jpg|}} |
| 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). |
| - 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: |
| |
| 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 ===== |
