[MPlayer-users] Re: [Patch] Re: Problem with -slave and A-V sync
Dirk Meyer
dischi at tzi.de
Sun Dec 3 18:45:18 CET 2006
Reimar Döffinger wrote:
> Hello,
> On Sun, Dec 03, 2006 at 01:13:42PM +0100, Dirk Meyer wrote:
>> I found the problem, but I can't really explain it. The problem is
>> that usec_sleep is called with 0 as sleeping interval some times. This
>> shouldn't be a problem, but it causes my problems. nanosleep seems to
>> sleep at least a very short time. The following patch resolves that
>> problem by catching the usec_delay == 0 before calling nanosleep.
>> Sounds stupid, but this fixes my problems.
>
> sleep always acts as a yield, i.e. it will cause a thread switch.
I know. Every system call will cause the scheduler to run in the
kernel.
> Though if this causes performance problems you either have
> 1) something else running that soaks up all the cpu time freed
No. I have a second core just doing nothing. There are other
processes, but my system is idle most of the time, at least the second
core.
> 2) a really bad OS where a yield is expensive even when only one process
> is runnable
Linux 2.6.18 doesn't sound like a bad OS to me. The funny part is that
the bug is only there when using -slave and the usleep stuff is in the
functions that reads the keys from normal input.
> Anyway, fixed in SVN r21468.
Thanks
> Btw. finding the cause is easy with gdb if instead of "return 0;" you do
> "*(char *)NULL = 0;"...
I don't understand. Without testing it, this should cause mplayer to
segfault and the gdb kicks in. But what can I do now? I can't go
deeper into the kernel after that point. What am I supposted to do in
gdb?
Greetings,
Dischi
--
There can't be a crisis today, my schedule is already full.
More information about the MPlayer-users
mailing list