Problems with Detect Idle CPU mode
 

First, I just wanted to say that I have been very happy with WinUAE... You
guys have been doing an outstanding job! I was especially impressed with the
improved sound with the new AHI drivers. however, I have a very serious
problem with chipset timings, and the "Detect Idle CPU" mode seems to be at the
root of it.

Let me explain:

With the Detect Idle CPU mode on, all chipset timing seems to be cut in
half - that is, the system clock loses about 30 seconds per minute, cursors
blink at half the selected speed, Paula audio breaks up terribly and just
sounds really slow. The audio problem is evident when using audio datatypes
and when playing MIDI files via GMPlay. MP3 playback, using the new AHI
drivers with AmigaAMP, is flawless.

With the Detect Idle CPU mode off, all chipset timings are (more or less)
correct), the clock runs at normal speed, all timed settings (cursor blink,
etc.) works as set, and Paula audio is (almost) flawless. However, all
non-chipset stuff, like RTG, AHI (using the new driver), disk I/O (non
hardfile), TCP/IP (internet, LAN, and networked drives) slow to an absolute
crawl. Here's an example: When viewing the contents of networked drive N:
(all my MIDI files), it takes about 20 seconds for all the icons to appear when
Detect Idle CPU is on, and about twelve minutes with it off!

This is a serious problem that is making me consider going back to 0821R4,
sacrificing some sound quality (and the return of the JIT/Copper bug) just to
bring some sanity back to my system clock and timings! What can be done about
this?

TIA

Nothing? No reply? Ten days and 51 views, and nobody has anything to say? No
hints, no suggestions, no "We're working on that, expect a fix in next release"
or anything?

*sigh*

I realize it's a complex problem, and that a fix may be months away; but it
would have been nice knowing that I'm not invisible, and that my problem has
been at least acknowledged.

In the meantime, I've since reverted back to 8.21.R4. I can learn to deal with
the clicking sound.

I apologize for the depressed tone of this message. I guess I was just hoping
I might get a little help with my problem. Thanks anyways.

Sorry, I just forgot to reply...

Slowdown in non-detect mode is a known bug (wrong priority in "expansion" device threads)

Note that idle detect is experimental feature that probably can't work perfectly ever...

Thank you for your reply.

The Idle CPU mode did help make things faster, but did have a bad effect on
chipset timing. Turning it off made the chipset timing worse.

I think the best solution is to scrap the Idle CPU thing entirely, but leave in
the improvements to the audio handlers. I mean, other than the timing
problems, I was really impressed with the improved sound quality, and with
finally the JIT/Copper bug problem going away! If one can merge the chipset
timing accuracy of 8.21.R4 with the bugfixes/audio improvements in 8.22.R1,
this would make WinUAE perfect IMHO.

Well, I for one find Detect CPU idle an important feature, compare 99% host processor usage to 20-40% on average when enabled. Chipset timings are much the same in my experience with this option, and sound is worse than ever in 8.22.R1. Heh.

With or without crap firewall software? :)

btw: when complaining about sound, always report tested sound buffer sizes! Especially because 0.8.17 and older, 0.8.21 and 0.8.22 use very different sound code, you just can't use old configuration and expect working sound.

ZoneAlarm is out of the picture now, after a clean format and reinstall. ;)

It's queer, sometimes it sounds just fine, other times there is the poping noise. As for the sound buffer, I always leave it on the third notch for smoothest playback, anything higher than this the sound is delayed, below this, begins to crackle.

Also, I dislike how the latest release steals the primary sound buffer when it has focus, so other apps utilizing DirectSound are unable to play in the background.