http://bugs.winehq.org/show_bug.cgi?id=60502 Bug ID: 60502 Summary: mf: audio renderer requests a sample after OnClockStop; music stops for good when a MonoGame game replays a song Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mfplat Assignee: wine-bugs@list.winehq.org Reporter: marepetru2015@gmail.com Target Milestone: --- Distribution: --- Created attachment 82360 --> http://bugs.winehq.org/attachment.cgi?id=82360 it's the test program, its source, three 2-second test songs, and a README with how to run it and the results on Windows and Wine. Found while looking into the Picross for a Cause crash (bug #60501). MonoGame 3.7.1 plays songs through IMFMediaSession and the streaming audio renderer. When a song ends it calls Start(position 0) and then Stop() right away, to reset the position. If the same song is then started again, the session plays nothing and sends no further events (no MESessionEnded), so the music stops for good. What goes wrong (wine-11.19-226-ga312fc87a5): 1. After OnClockStop, audio_renderer_render() can still run once from the audio client's buffer event. It finds its queue empty and queues MEStreamSinkRequestSample (sar.c:2151) without looking at the clock state, unlike the ProcessSample path, which only requests while the clock is running (sar.c:1590). In a trace this request comes about 7 ms after MESessionStopped. 2. The session handles that request while stopped and counts it as pending in the transform node (the WMA decoder). The source drops pending requests when it is started again from a position. 3. On the next Start of the same presentation, the renderer's new requests only increase the pending count ("there's already requests pending, just increase the counter"), so nothing is ever requested from the source again. On Windows 10 22H2 the attached program replays songs without problems. A small check on Windows (OnClockStop, then the pending request answered with a sample) showed no MEStreamSinkRequestSample after the clock stopped. Windows does keep requesting while prerolling with the clock stopped (test_sar_time_source: "A third sample is requested only after the first two have been delivered"), so it can't simply require a running clock. A direction that worked for me in a local build: in audio_renderer_render(), only queue the request when the clock isn't stopped or the renderer is prerolling (SAR_PREROLLED, which OnClockStop clears). The existing mf tests gave the same results with it. Note: I'm not a developer. This analysis and the test program were made with the help of an AI assistant (Claude). Because of Wine's policy on LLM-generated code I'm not attaching a patch. I'm happy to test patches. To reproduce: unpack mfrepro.zip and run, in its folder, "MFREPRO_DELAY=200 wine mfrepro.exe 30 1 s1.wma s2.wma s3.wma". It stops after "Play s3.wma (session state 0)", the first replay. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.