[geekmaster]

In my previous post, I linked to an old post of mine where I discussed how gmplay drops every-other frame if the frame-drop delay is much less than one second. The problem is a perceptual one, where dropping frames causes a discontuity -- a jump in the animation. Wherease allowing it to speed up and slow down (with up to a second of variable lag, but all frames displayed) is much less distracting. When the framerate is this low, every frame counts, and dropping only ONE can cause a noticeable and distraction jump in the moving characters on the display.

However, when integrating sound, speedups and slowdowns could be MUCH more noticeable than the visual equivalent, but dropping audio frames can also cause clicks and pops and other annoyances (depending on how it is encoded).

As I mentioned in that linked "bothersome" post, there are "DSP" (ring buffer) methods to speed up and slow down audio without skips and without frequency changes. That may be the way I keep audio and video in sync, while allowing up to one second latency to avoid visual skips due to variable eink update delays.

Synchronizing variable-latency video with fixed-latency audio is an interesting problem, when visual perception at such a low framerate has very little leeway for additional perceptual adjustments.

Another thing about frame dropping is that on my K2, the video runs smoothly for multiple frames, then has a very noticeable delay about once per second, every second, even while pausing the framework. I wonder what is going on there, which only seems to affect the K2... Perhaps some interaction with that one-second frame-drop latency?

In any case, the method of dealing with eink update latency and frame-dropping will need revisiting, ESPECIALLY with the addition of synchronized sound. Letting the video and audio get out-of-sync by up to +/- one-half second just won't do...