[mythtv] Slight choppiness question

[Sam N. Max (snx)]

----- Original Message ----- 
From: "skrpub" <skrpub at earthlink.net>
To: "Development of mythtv" <mythtv-dev at mythtv.org>
Sent: Thursday, August 07, 2003 11:22 PM
Subject: Re: [mythtv] Slight choppiness question


> There I found was that it would often wait 1/10 to 1/2 second waiting in
> RingBuffer::ReadFromBuf for data from the socket to fill the buffer,
> even if it was minutes behind the live recording

Just to make sure we are on the same line of thinking, the wait in this
function is due to the buffer not having enough data, which can happen
whether or not you are close to the end of the file.

> (For some tests, I set
> the resolution high and tuned to a channel with less than optimal
> reception, so there was some static in the picture. That gave very
> choppy video with the 1/2 second pauses.) There is a loop there that
> waits until ReadBufAvail() returns a large enough count. It often goes
> through the loop a dozen times, with each sleep actually being around
> 20ms instead of the 100us specified due to scheduler and timer resolution.

That sleep for all practicality is too long, though from what I can tell
shouldn't have to be called normally.

> It appears as if the readahead thread isn't reading when it can and
> waits until the buffer is too low. At that point, it takes too long to
> read while the consumer is waiting.

The read ahead buffer is 10 MB from the look of it, and it reads 128-256
kBytes blocks at a time.  My guess is the problem I'm having is not caused
by this, as I'm using mpeg4 with mp3 audio, so unless something *really*
wrong is going on in the read ahead thread it should be fine for non-live
stuff at the very least.  Maybe if you are using MJPEG that might be making
issues with the read thread more of an issue.

I notice there are a few oddities in the way thread synchronization/waiting
is done.  For example, if the buffer is paused, both the read ahead thread
and the ReadFromBuf function go into a loop to check if it's still paused,
and calling "usleep" if it's not.  This probably works reasonably, but using
something like pthread conditions would probably work better with less CPU
wastage (however there is a risk that this might not work as fast as the
usleep method, so don't take my word on it).

If the program is eating through the buffer fast, it's also possible that
the "sched_yield" call in the readahead thread may be causing the read
buffer to wait too long.  Each time a buffer is block (128-256KB) is read,
sched_yield is called.  I'm guessing the reason for this here is to prevent
the read thread from taking CPU from the record/playback threads.  This
probably shouldn't be called unless there is enough space in the buffer
(probably using the "fill_threshold" variable).  It appears there is a
"usleep" right before it which is trying to do something like I'm saying,
but the conditional usleep is likely useless right next to the sched_yield
which will have a greater impact on the priority of the thread.

- Eron