Page MenuHome

Audio not playing in sync over waveform when scrubbing
Closed, ArchivedPublic


System Information
Windows 7 Ultimate, 64-bit, 32GB, 5960x, Nvidia Quadro FX 1800 (Primary) & GeForce 9800 GTX+ (Secondary)
Graphics Tablet: Wacom Bamboo Model: CTF-430 Driver Version 5.2.4-5

Official release(s) unless specified:
Broken: 2.79

Exact steps for others to reproduce the error
If you can't play the video in your web browser, right-click the video --> copy link address (or equivalent) and play it in a media player like VLC.



Event Timeline

Philipp Oeser (lichtwerk) lowered the priority of this task from Needs Triage by Developer to Confirmed, Medium.

@Joerg Mueller (nexyon): could you have a look?

Joerg Mueller (nexyon) closed this task as Archived.Jan 31 2018, 2:26 PM

Hi, thanks for the report.

The synchronization is not the problem here, the problem is that a scrub is playing audio longer than just a single frame. Audio playback is buffered. You can't playback single samples (think of an audio sample as the equivalent of a single frame in a video), because the processing load would be too huge, since audio doesn't have eg. 30 or 60 frames per second, but 48000 samples per second. Now if the buffer is for example 4096 samples long, that's 0.0853 seconds long. In your example you have set the frame rate to 1200 Hz, which means that the buffer is about 100 frames long, of course way longer than a single frame. Even for the 24 frames you have, the buffer would be about 2 frames long, that's why you can also hear the frame after, when you scrub.

We could fix this problem by cutting the audio samples to exactly the frame borders, setting the remaining samples to 0 (silence), instead of playing the full scene and pausing after a buffer length. However, without going into details as to why, a simple implementation of this would render scrubbing useless since it would be very bad in performance and you would hear your scrubs a few milliseconds or even seconds after you scrubbed. Alternatively, a more complex implementation could also solve this without the huge performance drop, but I guess the effort would not pay off and we would get unnecessarily increased code complexity for a minor feature that hardly anyone notices (I guess so, since your bug report came in about 9 years after I took over the maintenance of audio in blender).