Bug 747750

Summary: Chapter 3. Real-Time and Low Latency
Product: [Fedora] Fedora Documentation Reporter: Jonquil <jonquil>
Component: musicians-guideAssignee: Christopher Antila <christopher>
Status: CLOSED EOL QA Contact: Nobody's working on this, feel free to take it <nobody>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: develCC: zach
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-11-07 15:30:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Jonquil 2011-10-20 22:16:49 UTC
Chapter 3. Real-Time and Low Latency
3.1. Why Low Latency Is Desirable
3.2. Processor Scheduling
3.3. The Real-Time Linux Kernel
3.4. Hard and Soft Real-Time
3.5. Getting a Real-Time Kernel in Fedora Linux
It is perhaps a common perception that computers can compute things instantaneously. Anybody who has ever waited for a web page to load has first-hand experience that this is not the case: computers take time to do things, even if the amount of time is often imperceptible to human observers. Moreover, a computer doing one thing can seem like it's acting nearly instantaneously, but a computer doing fifteen things will have a more difficult time keeping up appearances.
3.1. Why Low Latency Is Desirable
When computer audio specialists talk about a computer acting in real-time they mean that it is acting with only an imperceptible delay. A computer cannot act on something instantaneously and the amount of waiting time between an input and its output is called latency. In order for the delay between input and output to be perceived as non-existant (in other words, for a computer to "react in real-time,") the latency must be low.
For periodic tasks, like processing audio (which has a consistently recurring amount of data per second), low latency is desirable but consistent latency is usually more important. Think of it like this: years ago in North America, milk was delivered to homes by a dedicated delivery person. Imagine if the milk delivery person had a medium-latency but consistent schedule, returning every seven days. You would be able to plan for how much milk to buy and to limit your intake so that you don't run out too soon. Now imagine if the milk delivery person had a low-latency but inconsistent schedule, returning every one to four days. You would never be sure how much milk to buy and you wouldn't know how to limit yourself. Sometimes there would be too much milk and sometimes you would run out. Audio-processing and synthesis software behaves in a similar way: if it has a consistent amount of latency, it can plan accordingly. If it has an inconsistent amount of latency - whether large or small - there will sometimes be too much data and sometimes not enough. If your application runs out of audio data there will be noise or silence in the audio signal - both bad things.
Relatively low latency is still important so that your computer reacts imperceptibly quickly to what's going on. The point is that the difference between an 8 ms target latency and a 16 ms target latency is almost certainly imperceptible to humans but the higher latency may help your computer to be more consistent - and that's more important.

Comment 1 Karsten Wade 2011-12-14 03:48:41 UTC
Removing myself for these bug components as I'm either no longer involved in that aspect of the project, or no longer care to watch this particular bug. Sorry if you are caught in a maelstrom of bug changes as a result!

Comment 2 Petr Bokoc 2019-11-07 15:30:06 UTC
I'm closing this bug as part of a Bugzilla cleanup effort. The most likely reason is that the bug has been opened either against a component we no longer publish, or against Release Notes for an EOL release.