Buffer underrun

Look up underrun in Wiktionary, the free dictionary.

In computing, buffer underrun or buffer underflow is a state occurring when a buffer used for communicating between two devices or processes is fed with data at a lower speed than the data is being read from it. This requires the program reading from the buffer to pause its processing while the buffer refills. Having to deal with such situations can cause undesired and sometimes serious side effects because the data being buffered is often not suited for stop-start access of this kind.

In terms of concurrent programming, a buffer underrun can be considered a form of resource starvation.

The term as defined above is distinct from buffer overflow, a condition where a portion of memory forms a buffer of a fixed size yet is filled with more than that amount of data, thus overwriting memory locations outside of the allocated chunk. However, buffer underrun and underflow are also sometimes used to mean buffer underwrite, where a program is tricked into writing data into memory locations before the beginning of the buffer, overriding potential data there such as permission bits.^[1]

Buffer underruns are often the result of transitory issues involving the connection which is being buffered: either a connection between two processes, with others competing for CPU time, or a physical link, with devices competing for bandwidth.

The simplest guard against such problems is to increase the size of the buffer—if an incoming data stream needs to be read at 1 bit per second, a buffer of 10 bits would allow the connection to be blocked for up to 10 seconds before failing, whereas one of 60 bits would allow a blockage of up to a minute. However, this requires more memory to be available to the process or device, which can be expensive. It assumes that the buffer starts full—requiring a potentially significant pause before the reading process begins—and that it will always remain full unless the connection is currently blocked. If the data does not, on average, arrive faster than it is needed, any blockages on the connection will be cumulative; "dropping" one bit every minute on a hypothetical connection with a 60-bit buffer would lead to a buffer underrun if the connection remained active for an hour. In real-time applications, a large buffer size also increases the latency between input and output, which is undesirable in low-latency applications such as video conferencing.

Buffer underruns can cause serious problems during CD/DVD burning, because once the writing is started, it cannot stop and resume flawlessly; thus the pause needed by the underrun can cause the data on the disc to become invalid. Since the buffer is generally being filled from a relatively slow source, such as a hard disk or another CD/DVD, a heavy CPU or memory load from other concurrent tasks can easily exhaust the capacity of a small buffer. Therefore, a technique called buffer underrun protection was implemented by various individual CD/DVD writer vendors, under various trademarks, such as Plextor BurnProof, Nero UltraBuffer, Yamaha SafeBurn, JustLink, and Seamless Link. With this technique, the laser is indeed able to stop writing for any amount of time and resume when the buffer is full again. The gap between successive writes is extremely small.

Another way to protect against the problem, when using rewritable media (CD-RW, DVD-RW, DVD-RAM), is to use the UDF file system, which organizes data in smaller "packets", referenced by a single, updated address table, which can therefore be written in shorter bursts.

If the framebuffer of the graphics controller is not updated, the picture of the computer screen will appear to hang until the buffer receives new data. Many video player programs (e.g. MPlayer) feature the ability to drop frames if the system is overloaded, intentionally allowing a buffer underrun to keep up the tempo.

The buffer in an audio controller is a ring buffer. If an underrun occurs and the audio controller is not stopped, it will either keep repeating the sound contained in the buffer, or output silence depending on the implementation. Such effect is commonly referred to as "machinegun" or Max Headroom stuttering effect. This happens if the operating system hangs during audio playback. An error handling routine (e.g. blue screen of death) may eventually stop the audio controller.

Intentionally imitating this audio glitch during the creation of music or sound art, either by manually splicing audio or re-triggering samples, or by using plugins, is called the Stutter edit.