Lyra Operation Manual - Test and Measurement - Prism Sound

Prism Sound Lyra7 Technical topicsOperation ManualRevision 1.00The following sections contain detailed discussions of various relevant technical issues. The contentof these sections is not required to operate Lyra, but is provided merely as background information.7.1 Stability and latencyEver since audio production has found its way inside the computer, new problems concerning issuesof stability and latency have arisen.Pre-computer digital audio gear introduced the concept of delays through devices, which hadn'tusually been the case with analogue equipment. This was an inevitable consequence of samplingthe audio, and passing the samples through multiple layers of buffering during conversion,processing and interfacing operations. However, the 'latency' (buffer delay) was generally quite shortand didn't usually cause problems even in delay-sensitive applications such as live sound orover-dubbing. Reliable operation was generally guaranteed, since the digital devices wereessentially 'sausage machines' performing nothing but the same limited series of operationsrepeatedly.When general-purpose computers began to be used for audio production, problems with latency andstability suddenly had to be addressed. The reason is that computers are always busy doing otherthings than processing audio, even in situations where the operator is only interested in performingthat dedicated task. Because of this, the computer generally accumulates a large buffer of incomingaudio samples, which are then processed whilst a new buffer is being collected. Even though therequired processing can (hopefully) be accomplished faster than real-time (i.e. the sampleprocessing rate is faster than the sample rate), there is always the possibility that the computer maybe called upon to interrupt its processing of the audio in order to deal with some other essentialroutine task, such as maintaining screen graphics, moving data on and off disc, servicing otherprograms etc. In non-optimized systems, tasks such as collecting emails, virus-checking andcountless low-importance system operations can interrupt audio processing. Without theaccumulation of sample buffers, any interruption taking longer than about one sample period (1/fs)would cause incoming audio samples to be missed, resulting in disruption of the audio signal. Nearlyevery kind of interruption is long enough to do this. However, with a large enough buffer, theinterruptions don't cause audio to be disrupted so long as the computer has enough time availableduring the buffer period to process the entire buffer. This problem doesn't only happen for incomingsamples: audio outputs from the computer must likewise be buffered so that a continuous outputstream can be maintained even when the processor is called away for a while.Why is this a problem? First of all, the amount of latency required in order for a particular computerwith a particular audio processing and non-audio workload not to suffer audio disruptions can beproblematically large. This is particularly the case in live sound and over-dubbing situations wherethe delay between the computer's input and output has to be essentially imperceptible. This is oftendifficult or impossible to achieve, unless the computer has a powerful processor, a lot of memory, aheavily audio-optimized operating system workload, an efficiently written audio processing program,and not too many audio channels, not too much audio processing complexity, and not too high asample rate. The operator merely has to make sure that all these conditions are met, and all will bewell!But how do you do that? Even if we worry only about the computer and operating systemthemselves, the duration and frequency of interruptions is very non-deterministic: something canhappen very infrequently which causes a huge interruption. This might not be a problem: you canalways run that track again (assuming you noticed the glitch) - but what if you're recording animportant one-off live event? Even worse, the onset of trouble is greatly affected by audio factorssuch as number of tracks, sample rate, how many EQs are in use, etc. This makes the onset ofinstability even harder to predict reliably.On the other hand, situations where latency is critical are relatively few, so it is normally OK to© 2013 Prism Media Products Ltd1.42