Band-Limited Impulse (Blip) Sound Synthesis Explained for Game Audio

The word "blip" is used in two different ways in game audio, and the two are only loosely connected. The first is the short UI feedback sound: a 40-millisecond tone that confirms a button press. The second is the band-limited impulse — a single sample-height spike, spread across a few samples by a low-pass filter, that serves as the mathematical building block for anti-aliased oscillators. The first is what the player hears. The second is what makes the first possible in a digital system without turning into a hiss of aliasing noise.

The connection between them is not an accident of naming. The band-limited impulse is the cleanest possible short sound: all frequencies up to the Nyquist limit, nothing above it. When a game plays a short blip, what reaches the speaker is a shaped impulse. When a game emulates a vintage sound chip, the chip's square wave is built from a train of those impulses. The math is the same; the scale is different.

This article is about the band-limited impulse as a synthesis primitive, why a naive impulse aliases, how the sinc-based BLIT and the PolyBLEP/Blip_Buffer approaches suppress the aliasing, and where this connects to the short blip sounds that game UI depends on. The square-wave blip synthesis guide covers the audible result; this article is about the signal-processing foundation underneath it.

What is a band-limited impulse, and why is it not just a spike?

A true impulse, in the mathematical sense, is a single sample of infinite height and zero width. Its frequency spectrum is flat: equal energy at every frequency from DC up to infinity. In a digital system, that is a problem, because the system can only represent frequencies up to half the sample rate — the Nyquist limit. Everything above Nyquist gets folded back down into the audible range as aliasing noise.

A band-limited impulse is the impulse with all of its frequency content above Nyquist removed. The result is not a single sample. It is a sinc-shaped pulse that extends across several samples, with a main lobe at the center and smaller sidelobes on either side. The sinc function is the impulse response of an ideal low-pass filter, and a band-limited impulse is exactly that filter's output when fed a single-sample spike.

The sinc pulse has a useful property: its spectrum is flat from DC to Nyquist and zero above. It contains every audible frequency at equal energy, which is why it sounds like a click rather than a tone. A train of these pulses, spaced at a regular interval, is a band-limited impulse train — the BLIT that most virtual-analog synthesis is built on.

The difference between a naive impulse and a band-limited impulse is the difference between a click that sounds clean and a click that sounds like it is accompanied by a faint high-frequency whistle. The whistle is the aliasing, and it is the reason BLIT exists.

Why does a naive impulse train turn into aliasing noise?

An impulse train is a series of impulses spaced at a regular period. In the frequency domain, an impulse train produces a series of spectral lines at the fundamental frequency and all of its harmonics. The harmonics extend upward infinitely, with equal amplitude at every multiple of the fundamental.

In a digital system running at 44.1 kHz, the Nyquist limit is 22.05 kHz. If the impulse train's fundamental is 1000 Hz, the harmonics at 1000, 2000, 3000 Hz and so on are fine up to 22,050 Hz. But the train also has harmonics at 23,000, 24,000, 25,000 Hz and beyond, and those are above Nyquist. The system cannot represent them. They do not disappear; they fold back down.

Harmonic	Frequency	Status	Aliased to
1st	1000 Hz	Below Nyquist	—
22nd	22,000 Hz	Below Nyquist	—
23rd	23,000 Hz	Above Nyquist	21,100 Hz
24th	24,000 Hz	Above Nyquist	20,100 Hz
30th	30,000 Hz	Above Nyquist	14,100 Hz

The aliased harmonics land at frequencies that are not harmonically related to the fundamental. The 23rd harmonic folds to 21,100 Hz, the 24th to 20,100 Hz, the 30th to 14,100 Hz. The result is a cluster of inharmonic tones that the ear hears as a metallic buzz or a high-frequency whistle layered on top of the intended sound.

The aliasing gets worse as the fundamental rises, because the harmonics are spaced further apart and more of them land above Nyquist. A 5000 Hz impulse train at 44.1 kHz has harmonics at 5000, 10000, 15000, 20000, 25000, 30000 Hz. The 5th harmonic at 25,000 Hz folds to 19,100 Hz, the 6th at 30,000 Hz folds to 14,100 Hz, and the pattern continues. A high-pitched blip built from a naive impulse train is a blip with a whistle attached.

This is the problem that the arcade blip guide refers to when it says the real hardware sounded harsh. Part of that harshness was the aliasing from the naive waveform generation. Part of it was the narrow duty cycle. The two combined to produce the character that modern emulations try to reproduce without the aliasing component.

How does the sinc-based BLIT solve the aliasing problem?

The sinc-based BLIT replaces the naive impulse with a band-limited one. Instead of a single sample spike, each "impulse" is a sinc pulse that spans several samples and contains no energy above Nyquist. A train of these pulses still has harmonics, but all of them land below the Nyquist limit, so no folding occurs.

The sinc pulse itself has an infinite length in the mathematical ideal, which is not practical for a real-time system. The practical implementations use one of three approaches to make it finite.

The windowed-sinc approach. The sinc pulse is multiplied by a window function — typically a Hann or Blackman window — that tapers the sidelobes to zero over a finite number of samples. The windowed sinc is stored in a lookup table, and each impulse is generated by reading the table at the appropriate fractional offset. The table length determines the accuracy; a longer table produces a cleaner band-limited impulse at the cost of more memory. This is the approach the CCRMA BLIT-SWS method describes, and it is the one most software synthesizers use when memory is not the limiting factor.

The closed-form DSF approach. The Discrete Summation Formulae (DSF) provides a closed-form expression for a band-limited impulse train, without needing a lookup table. The expression involves sine functions and a division, and it is evaluated per sample. The formula allows the number of harmonics to be controlled directly, which makes it useful for synthesis where the bandwidth should track the pitch. The tradeoff is numerical cost: two sine calculations and a division per sample is expensive on a low-power processor.

The PolyBLEP approach. PolyBLEP does not generate a band-limited impulse train directly. It starts with a naive waveform — a sawtooth or square wave with discontinuities — and corrects each discontinuity by applying a polynomial approximation of a band-limited step to the samples surrounding it. The correction is a few lines of code, it runs in constant time per sample, and it suppresses aliasing well enough that the remaining artifacts are below the perceptual threshold. This is the technique that most modern game audio engines use, because it is efficient and the code is small enough to embed in a real-time oscillator.

Method	Memory	CPU per sample	Aliasing suppression
Naive (no BLIT)	None	Minimal	None
Windowed sinc table	4 to 64 KB	Low (table read)	High
DSF closed-form	None	High	High
PolyBLEP	None	Low	Medium to high

The choice between them depends on the target hardware and the quality requirement. A desktop game with a modern CPU can afford the DSF approach. A mobile game with a tight frame budget uses PolyBLEP. A game emulator that is trying to reproduce vintage hardware exactly uses a sinc table because the table can be tuned to match the original chip's frequency response.

What does the Blip_Buffer library actually do, and why is it named after the blip?

The Blip_Buffer library is the clearest example of the connection between the band-limited impulse and the short blip sound. It is a C++ library designed for emulating vintage video game sound chips, and its name comes directly from the band-limited impulse that its synthesis is built on.

The library does not generate waveforms from a frequency parameter the way a standard oscillator does. Instead, it asks the game code to specify the time points where the waveform's amplitude changes — a square wave is two amplitude changes per period, a sawtooth is one — and it synthesizes the output by inserting band-limited steps at those time points. The steps are shaped by a BLEP (band-limited step) kernel that suppresses the aliasing that a naive step would produce.

The result is a square wave, sawtooth, or pulse with the same harmonic structure as the original chip, without the aliasing that a naive implementation would add. The frequency of the wave is determined by the spacing between the amplitude-change time points, which means the library can produce any frequency without changing its internal state. This is what makes it suitable for sound chip emulation, where the chip's clock rate and the output sample rate are not the same.

The connection to the UI blip is direct: the band-limited step that Blip_Buffer uses to build a square wave is the integral of the band-limited impulse. A blip is a short burst of that step response, shaped by an envelope. The library's name is not a metaphor; it is a description of the mathematical object at its core.

The Web Audio blip tutorial covers the browser implementation of a single blip. The Blip_Buffer approach is what a game emulator needs to reproduce a full sound chip, and the two share the same underlying synthesis primitive.

How does this connect to the short blip sounds in a game UI?

A UI blip is short enough that the ear does not fully resolve its pitch. What the ear hears is the shape of the envelope and the spectral content of the impulse that the envelope is applied to. If the impulse is band-limited, the spectral content is flat up to Nyquist, and the blip sounds clean. If the impulse is naive, the spectral content has aliased harmonics layered on top, and the blip sounds harsh.

This is the reason a square-wave blip from a naive oscillator sounds different from a square-wave blip from a band-limited oscillator. The fundamental and the first few harmonics are the same. The difference is in the high harmonics: the naive version folds them back down into the audible range, and the band-limited version does not. At a 40-millisecond duration, the ear is sensitive to that difference because the blip is short enough that the aliased harmonics are a significant fraction of the total energy.

The practical consequence for a game developer is that the choice of oscillator matters more for short sounds than for long ones. A sustained note masks its own aliasing because the fundamental is strong and the aliased harmonics are a small fraction of the total energy. A 40-millisecond blip has no time to mask anything; the aliasing is exposed, and it reads as harshness.

The square-wave blip synthesis guide covers the duty cycle and the pitch envelope that shape the blip's character. The band-limited impulse is the underlying primitive that keeps the character clean. A designer who is generating blips with a naive oscillator in a custom engine can often improve the result more by switching to a band-limited oscillator than by adjusting the envelope.

When does a game developer actually need to care about BLIT?

Most game developers do not write their own oscillators. They use the engine's built-in audio system, a middleware tool, or a browser API, and those tools already handle band-limiting internally. The Web Audio API's PeriodicWave is band-limited by the browser, and the engine's built-in synthesizers are typically band-limited at the hardware or software level. A developer using those tools does not need to implement BLIT.

The cases where BLIT knowledge is directly useful are narrower.

Writing a custom oscillator for a game engine that does not provide one. A developer who is building a retro-style game in an engine without a band-limited oscillator, and who wants the blips to sound clean, needs to implement one. PolyBLEP is the most practical choice for this case, because it is small, fast, and suppresses aliasing enough for game audio.

Emulating a vintage sound chip. A developer who is building a game that reproduces the sound of a specific arcade board or console needs to match the original chip's synthesis. The Blip_Buffer library and the BLIT approach are the tools for that, because they produce the same harmonic structure as the original hardware without the aliasing that a modern implementation would add.

Diagnosing a harsh-sounding blip. A developer who has a blip that sounds harsh and cannot figure out why can use BLIT knowledge to diagnose the problem. If the blip is generated with a naive oscillator at a high frequency, the harshness is aliasing. The fix is to use a band-limited oscillator or to lower the frequency. The blip frequency tuning guide covers the frequency ranges where this problem is most likely.

For a developer using a modern engine's built-in tools, the BLIT concept is background knowledge rather than a direct implementation concern. It explains why the engine's oscillator sounds different from a naive one, and it explains why a blip at a high frequency in a custom implementation needs more care than a blip at a low frequency. It is the kind of knowledge that is not needed until it is, and when it is needed, nothing else substitutes for it.

The band-limited impulse is the cleanest short sound a digital system can produce. The short UI blip is the most common short sound a game produces. The two are connected by the same mathematical object, and the connection is why a blip generated by a band-limited oscillator sounds different from a blip generated by a naive one. The difference is small in absolute terms and large in perceived quality, which is the definition of a detail worth understanding.