On Mon Nov 17 22:00:23 2025 +0000, Elizabeth Figura wrote:
Why would it be a problem with flushing? When we get a flush we immediately wipe the buffer, including data that is queued but hasn't been played yet. We don't wait for it, and shouldn't; the point of a flush is to discard everything as fast as possible.
The only place where send_sample_data() explicitly waits now in the running state is when get_write_pos() returns S_FALSE and that only happens due to DSoundRenderer_Max_Fill check. Then, that wait is 10ms wait of flush_event. Removing DSoundRenderer_Max_Fill will make setting that event a dead code (there is some handling in my later patch but that is a different aspect). It seems to me doing exactly that, just dropping that limit, makes send_sample_data() busy-loop waiting for output dsound buffer to get some space when full and this process is not aborted with flush_event? Unless I am missing something we can't just drop that logic without replacing it with something else entirely.