[mythtv] Prebuffering pause (again)

[bdillahu at peachbush.com]

Just some added "data points" if it helps somebody... (I'm understanding
this prebuffer to be a cause of the channel change speed arguments)...

I had a Win2000XP card hooked up... worked fine... fast (1 sec. or less
channel changes).

I changed out to (2) Avermedia M179 cards (recent Ebay round)... work
pretty well (couple of driver things, but once you get them going, great)...
Since these are now MPEG2 I activated XvMC... now channel change speed is
4+ seconds... I hadn't thought about the XvMC change at the same time... I
may test on that and try to see if its a factor of MPEG2 or XvMC.

Could something in this be why some people see the slow change problem and
others don't?

Bruce

On Tue, Dec 09, 2003 at 09:27:27AM -0800, Steve Brown wrote:
> EVIDENCE
> 
> This seems aggravated by xvmc and hdtv.
> 
> It occurs not just with ota playback, but also with recorded playback.
> 
> I've tried various combinations of "Experimental A/V Sync", "Extra Audio 
> Buffering" and "Jitter reduction" without noticable change.
> 
> I've read the dev and user lists and the concensus seems to be that this 
> is related to data not being available in time. Maybe low data rate or 
> max'ed cpu.
> 
> In my case, the cpu is 2.8GHz and the disk is SATA. CPU utilization is 
> only about 50%. I suspect there is plenty of cpu and no problem getting 
> data. When the "prebuffer..." messages start, the cpu utilization 
> actually goes down.
> 
> THEORY
> 
> Could part of the problem be the latency in the method used for 
> synchronism between the main thread in NuppelVideoPlayer and the 
> VideoOutputLoop thread it spawns in StartPlaying?  Currently, if a free 
> buffer isn't available, the thread usleeps for a while and tries again. 
> This means that when a buffer is freed by one thread, the other thread 
> still completes its usleep interval before getting back to work.
> 
> SUGGESTION
> 
> If the above is correct, could the QSemaphore mechanism provide lower 
> latency and maybe reduce the problem?
> 
> I'm inclined to try this and see, but first wanted some feedback.
> 
> I know this issue has already been discussed at length and hope I'm not 
> wasting your time.
> 
> Flame away,
> 
> Steve
> 

> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev