2009-04-21, 21:56
Just checked out svn and applied that multithread workaround patch. Will see if that fixes the multithreading for me on Intrepid ...
boba
boba
headache Wrote:FYI, at this moment I'm running hardy with linux kernel 2.6.29. This kernel is build using make-kpkg and the default .config from the original 2.6.24-23. I've no problems with off-balanced cpu usage playing HD (1080p) material. Using xbmc svn r19517 and mediastream r1470.
althekiller Wrote:The workaround is confirmed non-working in some cases. We're really back at square one on this issue.
althekiller Wrote:Could you build another 2.6.29 with the default config for intrepid and report back? I wiped my hardy partition to install slackware so I could downgrade all of those stupid libraries.
sandos Wrote:Or someone could diff the (resulting) configs?
althekiller Wrote:Could you build another 2.6.29 with the default config for intrepid and report back? I wiped my hardy partition to install slackware so I could downgrade all of those stupid libraries.
headache Wrote:I've build a 2.6.29.1 with the config of 2.6.27-11-generic (intrepid). Also with this kernel there is no off-balanced cpu usage playing HD (1080p) material.Well, shit!
Quote:In the weekend i'll try to use the 2.6.27-11-generic intrepid kernel on hardy. For this to work I also need to build a correct nvidia kernel-module on an intrepid installation.
boba23 Wrote:Yea confirmed, the patch didn't really make a difference for me as well.Use the full patch: http://xbmc.svn.sourceforge.net/viewvc/x...5&r2=19485
boba
ERamseth Wrote:Anyone bothered to try with Jaunty as it was released today? I plan on giving it a go later on...
Side note: whats the best or at least a really good sample to tax the CPU usage (or really just a generally good 1080p test sample)
I've seen the Killa sample talked about a lot and I've seen a lot of people mention planet earth samples...
bobb0 Wrote:please correct me if i'm wrong... i haven't been following this thread that closely.
with that (killa/planet earth) sample you're always going to max out your processor.
i believe the issue is that instead of evenly spreading the decoding process across the 2 cores, it is spiking one core while the other is relatively low and then it flips after a few seconds. if frames are dropped because one core is maxxed out while the other has cycles to spare, it's a problem.