[mythtv-users] Playback stoppy and go-y. Ie super-duper-uber-jittery.

[Greg Stark]

Trey Boudreau <trey at treysoft.com> writes:

> It *feels* like the frontend can't both suck down the next few frames and
> render the current batch at the same time. 'top' indicates 80% idle time.
> Unfortunately I don't have another machine with enough CPU to run a second
> HD frontend to compare against.

I tried recording something and playing it back instead of live tv and had the
same thing happen. My machine also is ~ 80% idle when this is happening.

The message about "prebuffering paus" consistently gets printed just as the
playback resumes. It's like it's prebuffering a bunch of frames for a while,
then playing a bunch of frames for a while, then prebuffering, then playing.
Without allowing any context switches to continue playing while prebuffering
is happening.

What it feels like to me is some sort of thread scheduling misunderstanding.
Something like the issues recently with sched_yield and OpenOffice where a
change in semantics made OpenOffice feel unresponsive. Or like the various
issues java implementations have had with scheduling on different platforms.

One thing that would cause exactly this behaviour would be if the prebuffering
thread was a higher priority than the playback thread.

I've just started looking at the code. There's no chance the playback engine
is a module that can be replaced with a different engine. Perhaps a low
overhead non-threaded implementation based on mplayer?

-- 
greg