BLADERUNNER: Investigate audio video desynch issues

[antoniou79]

People in GOG forums have reported this issue, and some have written that it was randomly fixed the next time they launched the game.

GOG's official trailer for the Blade Runner re-release is an example of said issue -- in this the sound plays noticeably earlier than the image / actor lips moving:
​https://www.youtube.com/watch?v=cb1n8nc-jMI

Potential causes:

• Installing the game on a slow drive (eg. external USB)
• Heavy CPU load on the machine due to other processes(?)
• Additional load from recording the gameplay?

[antoniou79]

One thing I've noticed is that it is possible to cause a video/audio desynch if running the game in windowed mode, and move the game's window around, while a video cutscene is playing.

[IlDucci]

Greetings. I started playing the Restored Content version and did the whole Act 1. The first videos played alright, but Eisenduller's Death (Start of Act 2) did have a A/V desynch.

I'm using Win7 x64, version 2.2.0git2888-g8ab9c8ec77, playing in Windowed mode. I moved the window so I could read other things in my Desktop, but during gameplay, not at a FMV.

[antoniou79]

Another way this was reproduced today was by calling the Ctrl+F5 menu and resuming the game.

[antoniou79]

Wrong ticket, sorry.

[antoniou79]

Assigning this to me.

[antoniou79]

Reverting the priority back to "normal" for this, as I need to off-load my tasks list for the next stable 2.2 version, and it's looking like I might not be able to properly attend to this within the available timeframe.

[antoniou79]

I just pushed a possible fix for one of the causes of audio-video desynch.

This fix addresses the situation, when moving the ScummVM window around, in which case the video stops immediately but the audio keeps playing until the stream queue is exhausted (audio stream queue stores audio ahead of time, up to 15 frames). Thus, upon "resuming" (after having stopped moving the window), the video would remain behind the audio.

With this fix, the video will catch up with the audio first, before resuming queuing of the audio again. This does mean that in order for the video to catch up, the audio will have to be silent for the frames that it already has "played".

​https://github.com/scummvm/scummvm/commit/772a38588c6712fdd89076ad49b0d03bacdaca18

I still want to look into the video decoder code too, to see if we can optimize it for speed, so that it can run faster on slower devices, but perhaps this ticket can be closed for now.

I will keep it open for another week or so, pending feedback.

[antoniou79]

Closing this, since feedback has been positive about the de-synching issue.