[Bug 60502] New: mf: audio renderer requests a sample after OnClockStop; music stops for good when a MonoGame game replays a song

[WineHQ Bugzilla]

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: [e-mail]
          Reporter: [e-mail]
  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.