https://bugs.winehq.org/show_bug.cgi?id=50733
--- Comment #23 from Zebediah Figura z.figura12@gmail.com --- (In reply to castaneai from comment #21)
I looked into this issue further. I got the current latest git master (23ffd0a7986421958c23cffce138afa389209920) and output the report of perform_qos.
The attached log shows that jitter is over 400ms regularly.
https://bugs.winehq.org/attachment.cgi?id=69625
The problem appears to be caused by the DirectShow's clock.
The jitter is negative, which means that the samples are arriving early (i.e. in time).
mpegpsdemux clips seeks (including seeks to the start of the stream) to a fixed segment that spans from the PTS of the first sample to the last, and both may be nonzero. In the case of MUSICUS!, the first PTS is about 0.39294. We incorrectly use the buffer PTS to report QoS events when we should be using the running time, so mpegpsdemux perpetually thinks that the last sample to arrive was stamped later than the one it is currently processing.
I was able to reproduce a similar problem with an MPEG-1 system file, though I didn't test with earlier Wine. My guess is that the bug was introduced by a3e7cfd4d7, and should be fixed by https://source.winehq.org/patches/data/201821.