On Sun May 4 23:21:00 2025 +0000, Brendan McGrath wrote:
This doesn't look right. Why would we pretend that sink requested anything? I don't see why this would be necessary or different comparing to a regular start sequence. I agree, and my original fix made it the sinks responsibility to request a new sample. But in my testing on Windows, I couldn't see the sink ever make a request for a new sample after the flush. So my assumption was that the design on Windows was that it was the client's responsibility to request a new sample (i.e. if you call flush, you also provide the next sample). But maybe my test was wrong. I'll see if I can write one that I can include in this MR (and I'll then fix the implementation if necessary). helpers names are not great Agree actually. I used restart as they were called from the `SESSION_STATE_RESTARTING_SOURCES` path. But I shouldn't be naming functions based on where they are called from. I'll rename them to `session_flush_sinks` and `session_flush_transforms`. I've just pushed a number of changes (which I've described in the MR description). But I found that the sink won't request a new sample if it has a request outstanding. Even after it is flushed and started in a new position. Under this circumstance, it is the clients responsibility to honor that outstanding request. But if no request is outstanding, then it does fall to the sink to make a new request. I've modified my MR to reflect those findings.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/7932#note_102730