[mythtv] Suggestion for improving SLOW channel changing inLiveTV.....

Tim McClarren 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 
then "pause".

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
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

More information about the mythtv-dev mailing list