[MPlayer-dev-eng] [PATCH] use timer-lx.c on darwin & osx

[Nicolas Plourde]

On 26-Apr-05, at 6:29 PM, Arpi wrote:

> Hi,
>
>
>>
>> On 26 Apr 2005, at 22:19, Nicolas Plourde wrote:
>>
>>> I ran some benchmark using both timer and my result are showing
>>> not much performance lost using timer-darwin.c(not taking cpu load
>>> into account).
>>> But has previously reported by Dieter Shirley <dete at mac.com>,
>>> usec_sleep is called way too often.
>>>
>>
>> The patch suggested by Dieter Shirley reduces the "fudge factor" from
>> 0.020 to 0.005, decreasing the number of calls of usleep(0) which  
>> under
>> MacOS X seems to give good results. The question is if this has a
>> negative impact for the other architectures. Anyone willing to take
>> some test?
>>
>
> sure.
> on linux, usleep()'s min. delay is 20ms, this is the cause for the  
> 0.020
> value (even usleep(0) delays 20msec). so do not change it, at least  
> for
> linux!
>

I made change to timer-darwin to use sleep_accurate(), I also just  
submitted a patch to resolve the
bug with -cache flag, turned out that InitTimer() was not called  
before usec_sleep().

Now to take full advantage of sleep_accurate we need to change  
mplayer.c like this

@@ -2457,6 +2457,15 @@
      }
      } else
#endif
+#ifdef SYS_DARWIN
+    {
+        current_module="sleep_darwin";
+        while(time_frame>0.000) {
+            usec_sleep(1000000*time_frame);
+            time_frame-=GetRelativeTime();
+        }
+    }
+#else
      {
      // -------- TIMER + SOFTSLEEP -----------
      float min=softsleep?0.021:0.005;
@@ -2474,7 +2483,7 @@
          while(time_frame>0) time_frame-=GetRelativeTime(); // burn  
the CPU
      }
      }
-
+#endif
}
//if(!frame_time_remaining){    // should we display the frame now?

Is That correct? here is the patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff_mplayer
Type: application/octet-stream
Size: 777 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20050427/c86ec2da/attachment.obj>
-------------- next part --------------

====
Nicolas Plourde <nicolas.plourde at sympatico.ca>