[uae] Re: Source code snapshot 20060505
- From: Richard Drummond <evilrich@xxxxxxxxxxxxxx>
- To: uae@xxxxxxxxxxxxx
- Date: Sun, 7 May 2006 02:23:13 -0400
Hi Kjetil
On Friday 05 May 2006 13:49, Kjetil S. Matheussen wrote:
> Abilitity to run e-uae with realtime priority in a stable way without
> stalling all other programs.
Which reminds me: I need to have a look at merging your realtime changes when
I have some time.
> I think this is the single biggest problem with uae on all platforms.
I don't think so. ;-)
> Is there a code point thats garantied to be reached within a set time?
> In case we can add a sleep in there. If not, having a higher priority
> thread that puts the main uae thread to sleep at specific intervals could
> work as well, I think...
There are no guarantees. In general, each 68k opcode will be executed in
roughly the same time (at least when not using cycle-exact mode), but the
emulation of various other hardware components is a lot more variable.
E-UAE shouldn't hog the CPU without sleeping, unless it detects that your
system is unable to sleep with a less than 10ms latency.
If cpu_speed=real, then E-UAE will try to sleep every frame (if there's any
free time after rendering a frame - and it can do a non-busy-wait sleep).
If cpu_speed=max, then you can use the cpu_idle= setting. This will make E-UAE
sleep when a 68k STOP instruction is executed by Exec (when it's idle). This
only works with OS-friendly software, though.
> Maybe most of the audio problems would be solved if uae ran realtime. Then
> the buffers could be set a lot lower than they are now.
The problem that Lorenzo is having, for example, from what he describes is not
a mere scheduling problem.
Cheers,
Rich
Other related posts:
