https://bugs.winehq.org/show_bug.cgi?id=53475
--- Comment #13 from Zeb Figura z.figura12@gmail.com --- (In reply to ilkka.prusi from comment #12)
So the filter state and event state can end in a conflicting situation if I understood this correctly?
Looking at the code more it might be attempting to write out rest of the sample after flushing was signalled
I'm not sure what you mean by a conflicting situation, but broadly, flushing is asynchronous relative to sample/EOS processing. Under normal operation it'll always happen on a different thread, and that means that a flush request can arrive at any point relative to where we are in dsound_render_sink_Receive() or dsound_render_sink_eos(). Continuing to process the current sample (and not checking for flushing every other line) is hence not necessarily wrong—the purpose of a flush is simply to prevent us from blocking for an arbitrary length of time.
So end of stream happens earlier than actually stopping playback?
Broadly, yes. Everything that happens here is buffered; we expect to receive sound and EOS notifications hundreds of ms before they should actually be rendered.
But a couple of lines earlier there's IMediaEventSink_Release() already so it is supposed to end? Is it only relying on actual object destroying happening at a later time?
IMediaEventSink is a different interface on a different object, and that Release() call should never be the last one—it's just there for refcounting correctness.
Maybe that function should just call IDirectSoundBuffer_Stop() to ensure it is ending cleanly? Or is there something conceptually different about end of stream rather than end of sample playback?
I think we could potentially stop the dsound buffer, yes. I don't know that it'd be worth doing—the current code works, and if we really wanted to improve it we'd need a much bigger fundamental rewrite—but as far as I can think of it wouldn't be wrong.