[geekmaster]

I think we should skip the vsync call and sync to the audio stream instead.

On a K3, it spends all its time in the eink update. The vsync does not really do anything on a K3 because it is set for 7FPS and the eink call returns at 7FPS average (+/- a little). Sometimes it waits a tiny amount of time, and sometimes it is a little late (compensated on next frame by next teu+=130.

The vsync is really there for the K4/K5 that have asynchronous eink updates (which return WAY before the eink is ready). You really must wait awhile on them before touching the framebuffer.

As I see it, we need two threads that each spend virtually all their time inside the update call (sound or eink). For any interactivity (scanning for keyboard or touchscreen events) we need a third GUI thread too.

Doing it with callbacks cannot work while the thread is almost ALWAYS stalled inside the eink update on a K3.

pthreads is not all that difficult. Even the ALSA docs say you need multiple threads (just like I suggested above).

And with threads, we can just use the tiny sound support I used in my "noisy rhythm" demo. With interleaved raw A/V input (compressed with gzip or other compression) we do not need all that "visual space hogging" AVI support.

IMHO.

Need sleep now. Will try adding threads and stripping out the fluff tomorrow. Tomorrow I will pick up where you left off here (or in a PM, whichever is newer).

After it works, I will add simple decompression inside this code so we do not need to pipe from zcat.

Or you do it. Whichever gets there first. Or I might add audio to my sound demo. I will sleep on it. Cannot make decisions now. TTYL...