Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
wiki:jack_latency_tests [2012/05/30 15:00] – ZKwnnrjfKpqQkAYjkTd 94.23.1.28 | wiki:jack_latency_tests [2013/06/02 15:45] – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | It's great to find somneoe | + | ====== JACK Latency tests ====== |
+ | |||
+ | Yet to be interpreted results on measuring [[http:// | ||
+ | |||
+ | <note warning> | ||
+ | |||
+ | ===== Demystifying latency ===== | ||
+ | |||
+ | Latency is one of those buzzwords which are often misunderstood by the layman or are indiscriminately bandied around as incontrovertible proof of the evident advantages of one' | ||
+ | |||
+ | I once watched this guy in an audio forum talk about how he got less latency if he launched jackd from the command-line, | ||
+ | |||
+ | So, leaving aside buzzwords, hype and urban legends, what is actually latency? [[http:// | ||
+ | |||
+ | 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. | ||
+ | |||
+ | A very clear case of audio latency is the time it takes to hear the sound of thunder after you watch lightning from a distant storm (actually visual perception has latency too, since light doesn' | ||
+ | |||
+ | ===== Latency sources ===== | ||
+ | |||
+ | There are many factors that contribute to the total latency of a given system. Some of the more relevant are: | ||
+ | |||
+ | * **Sound propagation through the air**: since it is a mechanical perturbation in a fluid, sound travels at comparatively slow [[http:// | ||
+ | * 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 " | ||
+ | * **Digital-to-Analog and Analog-to-Digital conversion**: | ||
+ | * **Digital Signal Processing**: | ||
+ | * **Computer I/O Architecture**: | ||
+ | |||
+ | ===== Does latency really, really matter? ===== | ||
+ | |||
+ | 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**: | ||
+ | * **Software audio monitoring**: | ||
+ | * **Live-effects**: | ||
+ | * **Live-mixing**: | ||
+ | |||
+ | In many other cases (such as playback, recording, overdubbing, | ||
+ | |||
+ | At the end of the day, it is not so much its size, but how well you use it. | ||
+ | |||
+ | ===== The smaller the better? ===== | ||
+ | TODO | ||
+ | ===== Capture latency, playback latency, roundtrip latency, huh? ===== | ||
+ | |||
+ | 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 ===== | ||
+ | |||
+ | [[http:// | ||
+ | |||
+ | 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/ | ||
+ | |||
+ | 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:// | ||
+ | |||
+ | {{: | ||
+ | |||
+ | {{: | ||
+ | |||
+ | 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, | ||
+ | |||
+ | 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.) | ||
+ | |||
+ | < | ||
+ | $ jack_delay | ||
+ | capture latency | ||
+ | playback_latency = 2048 | ||
+ | Signal below threshold... | ||
+ | Signal below threshold... | ||
+ | Signal below threshold... | ||
+ | 3104.419 frames | ||
+ | 3104.416 frames | ||
+ | 3104.415 frames | ||
+ | 3104.417 frames | ||
+ | </ | ||
+ | |||
+ | ===== Adjusting latency ===== | ||
+ | TODO | ||
+ | |||
+ | The [[http:// | ||
+ | |||
+ | 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, | ||
+ | |||
+ | Stable low-latency (≤10ms) on GNU/Linux can usually only be achieved by running [[https:// | ||
+ | |||
+ | ===== JACK Latency enigma ===== | ||
+ | |||
+ | JACK does report the port-latencies (run '' | ||
+ | The total latency depends on many factors: the bus (PCI, 1394, USB, Chipset), layers in between (DMA, IRQ) and of course the audio-interface itself. | ||
+ | |||
+ | On a modern computer systems all these factors plus their configuration (PCI latency, bus speed, CPU/bus freq scaling, data-packet-framing, | ||
+ | |||
+ | ==== Latency measurements ==== | ||
+ | |||
+ | Fons Adriaensen has written a utility to measure the total round-trip latency called '' | ||
+ | |||
+ | Even though the complete path of the digital audio-signal that adds latency is complicated, | ||
+ | |||
+ | The diagrams below show the the total // | ||
+ | |||
+ | The tests were done on Debian/ | ||
+ | |||
+ | {{: | ||
+ | {{: | ||
+ | |||
+ | ==== Interpretation and Analysis ==== | ||
+ | |||
+ | Let's have a closer look: | ||
+ | The diagrams below show the difference between the // | ||
+ | |||
+ | {{: | ||
+ | |||
+ | {{: | ||
+ | {{: | ||
+ | |||
+ | The small //residue// of additional // | ||
+ | However the results for USB-device is unexpected. | ||
+ | |||
+ | There are two things that the authors of this article do not understand (and may be bugs in JACK): | ||
+ | - It seems that for USB devices JACK // | ||
+ | - The latency reported by JACK is inconsistent. | ||
+ | |||
+ | Looking closer at these two issues: | ||
+ | |||
+ | **(1)** plotting the // | ||
+ | |||
+ | {{: | ||
+ | |||
+ | **(2)** understanding the inconsistencies of reported port-latency will require digging into the source-code of JACK. Trying to reproduce this behaviour with jack-1 might also shed some light on the issue. It may also simply be a misinterpretation of the reported values. The information collected here is a first step: to make the issue clear to the authors. | ||
+ | |||
+ | using '' | ||
+ | ALSA: use 2 periods for capture | ||
+ | ALSA: use 2 periods for playback | ||
+ | |||
+ | and '' | ||
+ | ALSA: use 3 periods for capture | ||
+ | ALSA: use 3 periods for playback | ||
+ | |||
+ | while jack_lsp -l (or [[http:// | ||
+ | | ||
+ | port latency = 1024 frames | ||
+ | | ||
+ | port latency = 2048 frames | ||
+ | |||
+ | |||
+ | "3 periods for capture" | ||
+ | |||
+ | Alas, total latency measurement can not tell which it is. | ||
+ | |||
+ | ===== References ===== | ||
+ | |||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | * A script to acquire the data using '' | ||
+ | |||
+ | ===== Raw data ===== | ||
+ | |||
+ | |||
+ | < | ||
+ | #UA-25, Linux 2.6.33.7-rt29 i386, jackdmp 1.9.6 | ||
+ | #JACK-cfg, measured lat [frames], measured lat [ms], nominal latency for record [frames], nominal latency for playback [frames], periods per cycle | ||
+ | #JACK-cfg: frames per period * periods per cycle / sample-rate / S: --sync | ||
+ | # | ||
+ | # values of ' | ||
+ | # | ||
+ | 4096*3/ | ||
+ | 4096*3/ | ||
+ | 4096*2/ | ||
+ | 4096*2/ | ||
+ | 2048*3/ | ||
+ | 2048*3/ | ||
+ | 2048*2/ | ||
+ | 2048*2/ | ||
+ | 1024*3/ | ||
+ | 1024*3/ | ||
+ | 1024*2/ | ||
+ | 1024*2/ | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | 64*3/ | ||
+ | 64*3/ | ||
+ | 64*2/ | ||
+ | 64*2/ | ||
+ | 32*3/ | ||
+ | 32*3/ | ||
+ | 32*2/ | ||
+ | 32*2/ | ||
+ | 16*3/ | ||
+ | 16*3/ | ||
+ | 16*2/ | ||
+ | 16*2/ | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | #HDA 1458:a002, Linux 2.6.33.7-rt29 amd64, jackdmp 1.9.6 | ||
+ | #JACK-cfg, measured lat [frames], measured lat [ms], nominal latency for record [frames], nominal latency for playback [frames], periods per cycle | ||
+ | #JACK-cfg: frames per period * periods per cycle / sample-rate / S: --sync | ||
+ | # | ||
+ | # values of ' | ||
+ | # | ||
+ | #2048*2 -> ALSA: cannot configure playback channel | ||
+ | #1024*3 -> ALSA: cannot configure playback channel | ||
+ | # | ||
+ | 4096*3/ | ||
+ | 4096*3/ | ||
+ | 4096*2/ | ||
+ | 4096*2/ | ||
+ | 2048*3/ | ||
+ | 2048*3/ | ||
+ | 2048*2/ | ||
+ | 2048*2/ | ||
+ | 1024*3/ | ||
+ | 1024*3/ | ||
+ | 1024*2/ | ||
+ | 1024*2/ | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | 64*3/ | ||
+ | 64*3/ | ||
+ | 64*2/ | ||
+ | 64*2/ | ||
+ | 32*3/ | ||
+ | 32*3/ | ||
+ | 32*2/ | ||
+ | 32*2/ | ||
+ | 16*3/ | ||
+ | 16*3/ | ||
+ | 16*2/ | ||
+ | 16*2/ | ||
+ | </ | ||
+ | |||
+ | ===== Acknowledgments ===== | ||
+ | |||
+ | Many thanks to Paul Davis and Stephane Letz for JACK and Fons Adriaensen for jack_delay. | ||
+ | |||
+ | This article was written by Robin Gareus and Luis Garrido and may be redistributed in terms of the GFDL. |