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,
really.
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
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
