[mythtv] Suggestion for improving SLOW channel
tim at 7thheaven.org
Sun Sep 11 02:15:39 UTC 2005
I just started looking at this.
I instrumented tv_play.cpp and some of RingBuffer.cpp with logging,
because I was curious why it was taking me just under 4s to change channels.
A bunch of this time is spent getting stuff paused and unpaused.
One thing I discovered is that RingBuffer.cpp has a loop in it that, I
think, can cause it to be sitting there doing very little for a long
period of time, while the other thread is waiting on it to finish up and
go into "pause".
If you take a look at RingBuffer::ReadAheadThread(void), you'll see that
it checks the flag to see if it should be paused, but if it's not
supposed to be paused, it enters the loop right below, where it promptly
sleeps for 50ms, and could conceivably sleep for 500ms! Using
"usleep()" seems bad to me... but I don't know anything about this code,
All the while, the other thread is waiting for this thread to finish and
I have a patch for this problem, which introduces a private member
function that is called both before and from within the loop to check if
it should short-circuit.
I also removed the usleep entirely, and instead have this reader thread
wait on an "interrupt" mutex which will wake up should the player thread
ask it to "pause".
With these changes my channel changing dropped to just under 1.5s... I'm
guessing someone who starts at 2s would get some improvement, although
maybe not quite as much as me.
It's not as much code as it sounds like, and only changes RingBuffer.h/cpp.
If someone wants to look at this, I'm happy to send the diff. I know
exceptionally little about Myth (although I've been using it for a year
or more, I just started futzing around in the code because the UI has
become increasingly arcane and confusing... it needs a serious overhaul
to make it all very simple for your average non-video professional).
Ed W wrote:
>> Main control logic's in tv_rec.cpp and tv_play.cpp. The various
>> threads they're stopping/starting live elsewhere, but should be easy
>> enough to find with grep.
>> And yes, this is how you speed up channel changing, not by coming up
>> with crazily overcomplicated schemes.
> It's a while back, but I was seeing about 800ms spent waiting for things
> to pause on a box with mythbackend local. It was pretty hard to figure
> out where the delays were though to be honest
> I *think* that some of the problem may have been due to the size of the
> network packets used in frontend to backend comms? So you have to wait
> longer than you think before the backend has recorded enough data before
> you actually start sending the first packets to the frontend? It's
> possible that an option to tune this size depending on whether the
> backend is local could be useful?
> Also I think the min number of buffered frames could be lower in some
> circumstances, eg hardware mpeg cards
> I still think that there is no need to wait for several of the pauses to
> actually hit their respective threads, eg audio. Can't see what harm
> comes if we ask for a pause, then retune, then start sending more audio
> data before the audio thread even noticed what we were trying to do?
> It's just a queue and apart from flushing the queue there is nothing
> else we can really gain by waiting for it to notice what we are up to...?
> ...OK folks, so there are some easy starting points. As Isaac said if
> you just go into the channel change function in *tv_play.cpp* then its
> possible to put in a few timing statements to see how long each stage
> takes. Then dig into the slow statements and add some timing statements
> in those and so on. This shows up how long the various "pause"
> functions take. I have actually posted a patch to do this a long while
> back, but the point is that its pretty easy to do and your info would be
> very useful
> Come on, lets see some action now!
> Good luck
> Ed W
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
More information about the mythtv-dev