Audio latency is the delay between an event and the corresponding sound or captured data. It accumulates across buffering, processing, transport, and conversion rather than belonging to just one software component.
How the pieces connect
Buffers let a system handle work in manageable chunks and tolerate variations in scheduling. Smaller buffers can reduce one part of delay but give the system less time to service each chunk. Larger buffers can provide more scheduling margin while increasing waiting time. The relationship is a practical tradeoff, not a rule that one size is universally best.
An everyday example
Listening to a live microphone through a computer can reveal the combined capture and playback delay. Playing an existing music file has different demands because the content is already available in advance. A wireless transport adds its own scheduling and encoding behavior, so comparing the two situations requires more than reading a single buffer setting.
Reading the information in context
A sample-rate value, advertised wireless version, or processor speed cannot independently establish end-to-end delay. Applications also vary in their processing and synchronization choices. The library provides no live latency test and does not ask for microphone permission. When evaluating an application workflow, distinguish measured round-trip delay from the size of one buffer reported by one component.
Audio
Note these before you change anything
Useful facts to have to hand while reading about audio latency and buffering.
- The default playback and recording devices
- Sample rate and bit depth in the device properties
- Enabled enhancements or spatial sound
- Driver name and version, and whether it is a built-in class driver or a vendor one
Audio: Playback (output); recording runs the other way
- Applicationplays a stream
- Audio enginemixes and resamples
- Audio driverbuilt-in class or vendor
- Codec or DACconverts digital to analogue
- Speakers or headphonesanalogue or USB
