On Sat, 2005-09-10 at 22:38 +1000, Lincoln Dale wrote: > Isaac Richards wrote: > > And yes, this is how you speed up channel changing, not by coming up with > > crazily overcomplicated schemes. > > i ran 0.17 for a while with setsockopt TCP_NODELAY to disable nagling. > i didn't verify whether it was a benefit but based on my perception of > delay, it shaved 100msec of various things. I think this would be safe for the RingBuffer data socket...
Just in case someone is interested in getting in there and speeding things up the RingBuffer is a major bottleneck in LiveTV. I actually made some small changes in this for the signal monitoring, basically allowing partial packets 256K packets to be sent after a timeout for remote frontends, but I ended up just padding the dummyrec output with null packets to get things working properly. We really need something like adaptive packet size and timeouts based on current data availability from the recorder. Right now we use the rate estimation (I think from libav) at startup which isn't entirely accurate. But when I fidgeted with these values a few weeks ago it just caused more problems, so I think the first thing to do is document the current code RingBuffer code.... -- Daniel
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
