I think this one is out of place, because it's only called here for a side effect.
Agree actually. I think I'm trying to do two subtly different things with the one flag. I've split it in to two flags now: 1. For discarding samples prior to the seek time (so we never write them to the output buffer); and 2. For reporting the seek time up until the audio being played is past it So basically, the first flag handles the writing of the samples and the second the reading. So now the only impact of the new flag (`SAR_REPORT_SEEK_TIME`) is within the `GetCorrelatedTime` function; hence I think it makes sense to clear it there.
Also it's using IAudioClock::GetPosition() to reset this flag, while we use GetPosition() in render() itself, without any changes to seek flag. All of that might work, it's not easy to see if it does.
Yes, `GetPosition` provides the position within the buffer from where audio is currently being read. So in `audio_renderer_render`, it also adds the `pad_frames` to calculate where in the buffer it will be writing. We then associate that writing position with the PTS of the sample being rendered. That way we can calculate the timestamp of what is currently being read by applying the delta of `GetPosition` to that writing position with respect to the associated PTS. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10126#note_131924