So, in continuing to look at this, one other thing that is probably slow
in my setup is that I use the Perl "changechannel" script to change
channels on my Sony DSS receiver, which is connected over the serial line.
History tells me that forking and then launching Perl just to process a
30 line script to send commands out the serial line is probably not that
efficient.
I wrote a small module that is a serial line driver, and on top, a C++
driver class that can drive the Sony DSS. I tried to make it somewhat
modular so one could replace the Sony specific driver with code for
other receivers (with different byte code commands). So, this is C/C++
code that can be compiled into Myth. There's no UI component yet, since
I haven't fully learned how to do that. Also, I think this should be
non-blocking (it's not right now, but what I have is working). I can't
see any reason to actually wait 50 or 100ms for the DSS box to supply an
"OK" response to a command to change the channel. So, there ought to be
a callback that the driver can call to notify the caller when a command
failed. This would allow the mythbackend to attempt to resync state
with the receiver, and, if it fails for a period of time, to notify the
front end. The front end could then put up an OSD message to the effect
"The receiver connected to serial port X on your Myth server appears to
be malfunctioning", etc. I'd really like it if the front end was more
"user friendly" in this way, for all sorts of failure conditions. Comments?
I would like to polish this up and bit, but I will submit the "pause"
patches I mentioned below independently (hopefully later today).
Tim McClarren wrote:
Ah, my bad... I can't read my own logs :)
It was taking me just under 2s, not 4s.
The time-savings with this patch averages right around 400ms on my setup.
I am getting channel changes in the 1200-1500ms range now, vs.
1600-1900ms range before.
I still almost always get a "taking too long to be allowed to read.."
log message on the front end.
I'm guessing that's related to my encoding settings.
Tim McClarren wrote:
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
_______________________________________________
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
