Editing Real-time computing (section)

=== Real-time in digital signal processing ===
In a real-time [[digital signal processing]] (DSP) process, the analyzed (input) and generated (output) samples can be processed (or generated) continuously in the time it takes to input and output the same set of samples ''independent'' of the processing delay.<ref name="Kuo-Lee-Tian">Kuo, Sen M.; Lee, Bob H.; and Tian, Wenshun; "Real-Time Digital Signal Processing: Implementations and Applications", Wiley, 2006, {{ISBN|0-470-01495-4}}, [http://media.wiley.com/product_data/excerpt/54/04700149/0470014954.pdf Section 1.3.4: ''Real-Time Constraints''].</ref> It means that the processing delay must be bounded even if the processing continues for an unlimited time. The [[arithmetic mean|mean]] processing time per sample, including [[Overhead (computing)|overhead]], is no greater than the sampling period, which is the reciprocal of the [[sampling rate]]. This is the criterion whether the samples are grouped together in large segments and processed as blocks or are processed individually and whether there are long, short, or non-existent [[data buffer|input and output buffers]].

Consider an [[Audio signal processing|audio DSP]] example; if a process requires 2.01 seconds to [[Audio analysis|analyze]], [[Sound synthesis|synthesize]], or process 2.00 seconds of sound, it is not real-time. However, if it takes 1.99 seconds, it is or can be made into a real-time DSP process.

A common life analogy is standing in a line or [[Queue area|queue]] waiting for the checkout in a grocery store. If the line asymptotically grows longer and longer without bound, the checkout process is not real-time. If the length of the line is bounded, customers are being "processed" and output as rapidly, on average, as they are being inputted then that process ''is'' real-time. The grocer might go out of business or must at least lose business if they cannot make their checkout process real-time; thus, it is fundamentally important that this process is real-time.

A signal processing algorithm that cannot keep up with the flow of input data with output falling further and further behind the input, is not real-time. If the delay of the output (relative to the input) is bounded regarding a process which operates over an unlimited time, then that signal processing algorithm is real-time, even if the throughput delay may be very long.

==== Live vs. real-time ====

Real-time signal processing is necessary, but not sufficient in and of itself, for live signal processing such as what is required in [[live event support]]. Live audio digital signal processing requires both real-time operation and a sufficient limit to throughput delay so as to be tolerable to performers using [[stage monitor]]s or [[in-ear monitor]]s and not noticeable as [[lip sync error]] by the audience also directly watching the performers. Tolerable limits to latency for live, real-time processing is a subject of investigation and debate, but is estimated to be between 6 and 20 milliseconds.<ref>{{cite journal|last1=Kudrle|first1=Sara|last2=Proulx|first2=Michel|last3=Carrieres|first3=Pascal|last4=Lopez|first4=Marco|title=Fingerprinting for Solving A/V Synchronization Issues within Broadcast Environments|journal=SMPTE Motion Imaging Journal|date=July 2011|volume=120|issue=5|pages=36–46|doi=10.5594/j18059XY|quote=Appropriate A/V sync limits have been established and the range that is considered acceptable for film is +/- 22 ms. The range for video, according to the ATSC, is up to 15 ms lead time and about 45 ms lag time|display-authors=etal}}</ref>

Real-time bidirectional [[G.114|telecommunications delays]] of less than 300 ms ("round trip" or twice the unidirectional delay) are considered "acceptable" to avoid undesired "talk-over" in conversation.