mirror of
https://github.com/ARMSX2/ARMSX3.git
synced 2026-08-24 16:58:52 -07:00
A callback the backend cannot fill completely is a hole in the output: the device asked for N frames, the emulator did not have them, and the gap is filled by repeating the last sample. That is what crackling IS, and nothing counted it. The buffer-level report samples every ten seconds while a starved callback lasts milliseconds, so every transient underrun passed between samples unseen -- a Call of Duty: World at War capture shows a perfectly healthy buffer (queued 22.7-48ms against a 36.7ms target, never near dry) through a session where the audio was audibly breaking up. Counted in AudioBackend rather than per backend so Cubeb and Oboe report the same number the same way, one count per starved callback rather than per padded frame -- the audible event is the gap, and its length is already implied by how much of the callback had to be invented. Reported on the existing audio line as a delta since the previous one, not a running total: what matters is whether the output is breaking up now, and a total from a rough patch minutes ago hides that.