[XMA] Reserve headroom per decoded frame and account for it in gating

The 3-bit field at +24bit in DWORD 1 of the XMA context was named
subframe_skip_count but never actually used for skipping subframes.
Testing across multiple titles (PGR4, Halo Reach) shows the field
might control extra output buffer blocks that must be reserved per decoded
frame. Renaming the field to output_buffer_padding to reflect this
observed behavior and adding padding to the minimum output space threshold

Pdding blocks are reserved from the output budget after each frame is
fully consumed, preventing the decoder from overrunning the space
that the game expects to remain free.

This is still likely not entirely correct but reduces some of the
observed noise in current implementation.
This commit is contained in:
Herman S.
2026-02-18 18:05:57 +09:00
parent 83d776fa39
commit d9747704be
2 changed files with 22 additions and 18 deletions

View File

@@ -68,11 +68,15 @@ struct XMA_CONTEXT_DATA {
uint32_t loop_subframe_skip : 3; // +17bit, XMASetLoopData might be
// subframe_decode_count
uint32_t subframe_decode_count : 4; // +20bit
uint32_t subframe_skip_count : 3; // +24bit
uint32_t sample_rate : 2; // +27bit enum of sample rates
uint32_t is_stereo : 1; // +29bit
uint32_t unk_dword_1_c : 1; // +30bit
uint32_t output_buffer_valid : 1; // +31bit, XMAIsOutputBufferValid
uint32_t output_buffer_padding : 3; // +24bit, extra output buffer blocks
// reserved per decoded frame
// NOTE(has207): this is pure guess
// but that's how we're using it
// currently
uint32_t sample_rate : 2; // +27bit enum of sample rates
uint32_t is_stereo : 1; // +29bit
uint32_t unk_dword_1_c : 1; // +30bit
uint32_t output_buffer_valid : 1; // +31bit, XMAIsOutputBufferValid
// DWORD 2
uint32_t input_buffer_read_offset : 26; // XMAGetInputBufferReadOffset