by Chris » Sun Sep 25, 2022 8:51 pm
Graf Zahl wrote: ↑Sun Sep 25, 2022 2:15 am
The delay with the audio comes from OpenAL's rather high latency. This may need input from Chris to solve - I have no idea how to get around it.
From a quick look in
src/common/cutscenes/movieplayer.cpp, it looks like it may need an overhaul. The audio seems to be handled as fire-and-forget, and expects the sound to automatically synchronize with the video even though there's no mechanism in place to make it do so. Even if there was absolutely 0 latency, there's nothing stopping the audio from desyncing due to timer drift (the audio device's clock ticking at a subtly different rate than the main system's clock, which builds up over time). Different systems experience different amounts of drift between different devices, so what seems to work fine for some people may noticeably desync for others.
The movie's audio stream needs to synchronize with the same timing source as the video, and it works best when audio samples are streamed with a queue since it allows more precise timing control. The trick is to be able to measure and correct for the difference in playback position of the audio and video as they play (using the audio sample currently at the DAC, or the video frame being shown, not the decoder position) relative to some "master clock" (a timer used to indicate what timepoint the audio and video should be at for the movie). OpenAL Soft allows getting the sample position at (or relatively close to) the DAC for a given sound source, so it's capable of synchronizing an audio stream with video regardless of what latency there may be.
Audio plays asynchronously, so if you just play it while showing some video frames, there's no guarantee it'll play correctly. Instead, the movie player needs an audio handler to keep tabs on the audio stream playback position along with the movie's master clock. If the audio is detected to be running behind, you skip some samples the next time the audio stream wants some so it "fast forwards" and catches up, and if the audio is ahead, you push some extra samples into the stream to hold it back.
I'll try to play around with it when I get some time, but this is an area I'm unfamiliar with so it may take time.
[quote="Graf Zahl" post_id=1229340 time=1664093724 user_id=75]
The delay with the audio comes from OpenAL's rather high latency. This may need input from Chris to solve - I have no idea how to get around it.
[/quote]
From a quick look in [c]src/common/cutscenes/movieplayer.cpp[/c], it looks like it may need an overhaul. The audio seems to be handled as fire-and-forget, and expects the sound to automatically synchronize with the video even though there's no mechanism in place to make it do so. Even if there was absolutely 0 latency, there's nothing stopping the audio from desyncing due to timer drift (the audio device's clock ticking at a subtly different rate than the main system's clock, which builds up over time). Different systems experience different amounts of drift between different devices, so what seems to work fine for some people may noticeably desync for others.
The movie's audio stream needs to synchronize with the same timing source as the video, and it works best when audio samples are streamed with a queue since it allows more precise timing control. The trick is to be able to measure and correct for the difference in playback position of the audio and video as they play (using the audio sample currently at the DAC, or the video frame being shown, not the decoder position) relative to some "master clock" (a timer used to indicate what timepoint the audio and video should be at for the movie). OpenAL Soft allows getting the sample position at (or relatively close to) the DAC for a given sound source, so it's capable of synchronizing an audio stream with video regardless of what latency there may be.
Audio plays asynchronously, so if you just play it while showing some video frames, there's no guarantee it'll play correctly. Instead, the movie player needs an audio handler to keep tabs on the audio stream playback position along with the movie's master clock. If the audio is detected to be running behind, you skip some samples the next time the audio stream wants some so it "fast forwards" and catches up, and if the audio is ahead, you push some extra samples into the stream to hold it back.
I'll try to play around with it when I get some time, but this is an area I'm unfamiliar with so it may take time.