On Thu Oct 17 01:13:41 2024 +0000, Elizabeth Figura wrote:
You can register a callback to allocate buffers; that's the point of this code and this sanity check. If there's no such callback then we allocate them ourselves.
If I recall correctly, the application doesn't set any custom allocator, so we get "default" allocation behavior.
What happens for the game (and identically if you e.g. hack the relevant .wmv video from the game into wmvcore/tests/wmvcore.c:test_sync_reader_streaming()) is that all the output audio samples have size (in the `INSSBuffer_GetBufferAndLength(sample, &data, &size);` sense) between 8KiB and 16KiB and "capacity" (as in `INSSBuffer_GetMaxLength(sample, &capacity);`) 17208. So that means, as I understand it, that native is doing something more complicated than what this patch does, but the general effect is more or less the same.
I could restore that sanity check (but checking with the `size` value I compute immediately after), it's just that it seems somewhat redundant. We just asked for a buffer large at least `capacity` and got a non-`FAILED(hr)` response, I'd be quite surprised if whatever serviced the allocation request lied to us.