[uae] Re: Source code snapshot 20060505
- From: "Kjetil S. Matheussen" <kjetil@xxxxxxxxxxxxxxxxxx>
- To: uae@xxxxxxxxxxxxx
- Date: Sun, 7 May 2006 16:56:30 -0700 (PDT)
On Sun, 7 May 2006, Richard Drummond wrote:
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.
It wasn't very easy to make it reliable. I had to add sleeps
in the midi poll routine to avoid letting it hog the cpu for too long,
or perhaps it was because it used too much cpu.
But anyway, it would be nice to have realtime as an option, even without
extra sleeping. The watchdog I added have proved to work very good, no
resets of the machine have been necessary, and I have used it a lot.
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.
Okay. I guess a seperate
put-uae-to-sleep-with-regular-intervals-except-in-certain-situations
thread could be the best solution then. I think I will look at this after
my exams.
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.
Thanks.
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.
But running audio reliable does in theory require realtime priority
though, unless you have very large buffers.
Other related posts:
