mirror of
https://github.com/ARMSX2/ARMSX3.git
synced 2026-08-24 16:58:52 -07:00
jpolo1224
3a7c4f2061
average_playtime_ratio divided m_average_playtime -- a rolling average of get_enqueued_playtime(), in microseconds -- by audio_buffer_length, which is a sample count (AUDIO_BUFFER_SAMPLES * channels, 512 for stereo). The result was microseconds per sample: roughly 78 on a healthy stereo buffer and never below 1, so the 'not as full as desired' branch it gates has not executed once since it was written. The buffer target has therefore always been the fixed desired_buffer_duration + half a block, with the adaptive widening silently inert. Wrong from introduction rather than drifted: m_average_playtime has been a duration since before that line existed. audio_buffer_length had no other reader anywhere in the tree, which is why nothing caught it; it is deleted here so it cannot be picked up again by mistake. The denominator is now desired_buffer_duration, which is what the comment above it names and the only choice that makes the branch meaningful -- audio_block_period would leave the ratio near 7 and the branch just as dead. Guarded against a zero denominator, and the existing max(ratio, 0.25) clamp still bounds the widening at 4x. This arms a path that has effectively never run, so it changes behaviour for every game: a consistently under-filled buffer now raises the target instead of being ignored, trading latency for fewer dropouts. That is what it was written to do. The audio buffer report added alongside prints the ratio, so the effect is visible in a log rather than inferred.
