[Bf-committers] Blender and the "Sync" story

[Alexander Ewering]

Hello,

I guess all this confusion about the "Sync" option and
the changes introduced by my audio subsystem need some
more explanation. It can already be found at

http://intrr.org/blender/audiosequencer.html

but I'll now give a more detailed insight.

Traditionally, when you are in ALT-A (animation preview)
mode, Blender sets a timer before rendering a frame via OpenGL.
As soon as it is rendered and displayed, it waits until the
timer has reached 1/25 second, or whatever has been set in
the "AnimSpeed" button (which I removed in 2.28).

This approach has several problems:

 - If the scene is too complex for the graphics card to
   draw in 1/25 second, the animation preview will be SLOWER
   than it will be in the final render, which makes timing
   animation IPOs etc. difficult and requires lots of test
   renders.

 - Using the 'AnimSpeed' button, you could not set arbitrary
   framerates. Only 25 fps, 33 1/3 fps or 20 fps were possible.

 - With my integration of audio globally in Blender's animation
   system, the need arised to have the animation preview (alt-a)
   ALWAYS display in actual time, i.e., frame 100 is at exactly
   4 seconds, no matter how complex the scene is. It is undesirable
   to skip or repeat portions of the audio in order to stay in 
   sync with the video.

In general, Audio playback is not as CPU-intensive as Video
playback, so the industry standard is to let the audio play at
its realtime speed, and to drop frames in the video to keep it
synchronized. This is how I have implemented it in blender, and
it has advantages:

 - You do NOT have to do test renders for testing timing. Your
   animation will ALWAYS show 'actual time'.

 - You can set any integral value for the framerate

and disadvantages:

 - The framedrop obviously makes the animation preview a bit
   more 'choppy' for complex scenes where the GPU is behind,
   but this is impossible to avoid, Blender can't speed up your
   graphics card

 - Bad soundcards / Bad drivers / Bad SDL implementations / Bad
   mixing buffer size settings can adversely influence
   ALT-A performance

This is because since Blender 2.28, Blender doesn't simply increase
the framenumber anymore when it has displayed a frame, but it
_calculates_ the framenumber from a 44.1 or 48 kHz reference clock,
which resides in a chip on your soundcard. It does this EVEN
IF NO AUDIO STRIPS ARE USED AT ALL.

So if your sound card delivers bad/choppy sample position
information, your animation preview will be bad/choppy as well.

That's what the 'Sync' button is for. If it is turned off, it
will make Blender use its old timing approach. Obviously, this
will make the audio sequencer completely unusable.

For me, having actual time in alt-a makes a big advantage,
so i thought it was totally obvious that everybody will always
want the 'Sync' option. I didn't even think about the ability
to turn it off at first :-)

If the Sync option makes animation preview choppy, different
mixing buffer sizes in userprefs should be tried. If that doesn't
help, other drivers / other soundcard (i use an Ebay $10 SB PCI 128
with excellent results) should be tested.

I've now made the Sync option OFF by default (popular request,
I won't mention names :-)), default meaning: if a pre-2.28
.B.blend or pre-2.28 .blend file is encountered.

I hope this cleans ideas up a bit :-)

| alexander ewering           instinctive new media
| ae@instinctive.de       http://www.instinctive.de 
|
| fon: +49-2393-220558         fax: +49-2393-220559