There are several things to consider:

• OpenMPT's renderer is single-threaded.
• Atom is a weak CPU. It does not scale the same way as those processor "recommendations" that you find next to the polyphony settings.
• Furthermore, those recommendations are probably meant for 44KHz, certainly not 88KHz, so you will have to multiply them by at least two (more for Atom, actually)
• They are probably also not meant for the best resampling settings, which take a lot more CPU time (the last time I tested OpenMPT on a 850 MHz Pentium 3, it could barely keep up when using Polyphase or XMMS resampling at 44KHz, Cubic was fine though, so I'm relatively sure those recommendations where made with Cubic resampling in mind).
• There are many factors which influence how many channels you can play at once, one very limiting factor are resonant filters. Since they are rendering using floating point precision in OpenMPT 1.20-1.22, they require substantially more CPU power than an unfiltered channel.

Now while OpenMPT's mixing code has not changed between 1.20 and 1.22, what has changed is the flexibility in how OpenMPT wastes CPU time. :) In OpenMPT 1.20, the GUI update interval was fixed at one eighth of the buffer length. In OpenMPT 1.22, the GUI update interval is independent from this setting and by default is very fast and thus CPU-intensive. In your setting, I'd recommend to use a high update interval of maybe 20+ milliseconds.
Please consider this FAQ entry: http://wiki.openmpt.org/Manual:_Frequently_Asked_Questions#OpenMPT_produces_clicks_at_a_buffer_length_that_previously_worked_just_fine

Well, i already read and understood this.

i played around with the latency, update and boost priority settings.
I experienced that a latency of 75ms with update 5ms and "boost" runs better (at mean high load) than e.g. 250ms with 20ms update with or without boost - in keeping constant buffer/latency.
So well optimised for fast systems!

The 250/20 combi runs more likely into gaps than it should, 'cause it manages to run into half buffer "by chance", before "the real action" starts. But 250/5 seems to give a bit more load, so it runs out a bit later than.

Just a silly question: update and boost are for both the player code, and the gui? There is only one separate update-vu-meter setting in the .ini (which i set to 50), nothing else?

Can you add a separate update gui setting, or boost the player only?
like 1.20 and its predecessors seem to do it - sometimes the pattern scroll "hooks" for half a pattern - but only with system sound drivers (where the gaps, if, are buffer loops) - seems the other report the buffer state not fast enough (there the gaps are real silence with distortion).

Cpu - so an Atom is worse than a P2?
my guess was Samplingrate doubles and polyphase doubles so it's 400x4 - i suppose multitasking and hyperthreading eat up their bit too.
Don't really know how hyperthreading works, but only 900MHz per Core would perfectly explain the "weakness".

And i can see the system shift the load from 1 virtual core to the next during playback, that surely doesnt help too.

Cpu - so an Atom is worse than a P2?

Just a silly question: update and boost are for both the player code, and the gui?

You should always leave "Boost thread priority" enabled if it does not cause any problems for you. It has the risk of completely stalling the GUI if the sound thread consumes too much CPU time.

The silly question you are asking is not silly at all. The latency, update interval and thread priority boost settings primarily affect the sound player code only. The update interval of the GUI is currently coupled to the update interval of the player thread. This, in fact, does not make all that much sense, and I have been planning to decouple those for some time now. I'll look into that in the next days.

Generally, using the default waveout driver should be the best option for slower system (you figured that out already). For Windows Vista/7/8, you could also try using WASAPI in non-exclusive mode.
For standard waveout drivers, i would suggest something like 200/50/boost for your system. Especially, keeping update interval 20ms or below means that your GUI basically redrawn at 50Hz or greater rate which could very well be too much for your system.

Regarding Atom CPUs in general. Yes, they are slow. I do not have any meaningful comparison with Pentium 2 class chips, but my best guess would be, that the performace per MHz for a single core could in fact be lower for the Atom. However, OpenMPT is not really tuned for Atom at all. It's possible that using polyphase resampling hurts more on Atom than on other CPUs (just guessing here). As SagaMusix noted, OpenMPT is using floating point for the resonant filters in 1.20 to 1.22. This could also hurt Atom more than other CPUs as OpenMPT does not use SSE for floating point. This changed recently and resonant filters do not use floating point at all currently, so can you try if http://buildbot.openmpt.org/builds/auto/openmpt-win32/openmpt-win32-r3671.7z performs better for you?

Thanx manx!
Now i have constant performance with 128 voices 250ms latency and 5ms period (yes, longer still tends to hick-up) with 96khz and FP - now again a little bit faster than 32bit.

But... i heard a little bubbling and therefor tested filtering with jeff93 (Drifting onwards): what was (.16) a continuous filter freq. down in the last three patterns is now (.19) discrete jumping ;-(

• maybe provide another switch in options?

and (now really OT) .19 doesn't import midi files at all...

The integer filter has some artefacts (but it's just as smooth as it's ever been), yes. I'm not sure if those can be fixed. However, the plan is to make the whole mixer (including filters) floating-point for the next release anyway, and provide the integer mixer only as a fallback option for systems that have slow floating point instructions (e.g. ARM), so at least on Windows this is just a temporary issue.

Regarding MIDI (also affects MDL/MED/MT2) import, this problem will be fixed soon.

EDIT:
Those "bubbling" filter artefacts are the same as in OpenMPT versions older than 1.20. They shouldn't be there, and they are only there because of a silly typo. Thanks for spotting them! They should be fixed soon.

Thanx Saga,

Another one:
AGC* is a bit buggy now, in seldom circumstances. Not in the 40 songs tested up to lunch, but now for "last_return.it" - .16 works normal, .19 gives hard clipping of bass/drum starting mid. of 2nd pat. (haven't heard such for years, took some time to remember the English wording) - maybe the output of the sse/int filter is not normalized like the fp filter; as filter output can sometimes be higher level than input?

• first guess, maybe it's already clipped in the output of the int filter if there is no reserve bit

maybe the output of the sse/int filter is not normalized like the fp filter; as filter output can sometimes be higher level than input?

Anyway, the filter and MID stuff is fixed now: http://sagagames.de/stuff/mptrack.exe

Thanks a lot,
This one is resolved for me!

the mixing will be fixed, soon...

i had a little hope - but this one:
bugs.openmpt.org/view.php?id=462
is still there (since the 1.20.xx)

Yes, and it will stay there probably until a complete rewrite of MIDI import has happened. I am not interested in fixing MIDI-related bugs.

Also, since r3676, you can now set the GUI update interval separately from the audio period. Set e.g. [Display]GUIUpdateInterval=50 in the ini or use the Advanced settings tab. The unit is milliseconds, a value of 0 uses the old code which couples the GUI update interval to the audio period again. I have not tested that extensively yet, so there might still be some problems.
Wild guess, try something like 100/5/boost for the audio, and GUIUpdateInterval=50 or greater.
You can find a current version at the usual place at http://buildbot.openmpt.org/builds/auto/openmpt-win32/ . Newer versions are at the top.

hi folx, unfortunately i was very busy and hadn't much time for testing.
The decoupling of gui and audio update works, but seems to tend to "hickup" more than leaving both coupled.
at least at my machine.
i suppose the 1x - 3x weak peek to strong peek (audio to audio+gui update) alteration of cpu load is not well handled by the system.
For me the return to int filtering made the fix, i can now permanently run 128 voices without stutter (independent from manx' gui setting). if i shall make a rough guess: i can run around 150 voices with gui "0" and around 135 with other gui values - but the voice N° setting isn't this fine, and i didn't make special test songs.

Hi again! in bed with flu, cough and time i got the 3801 build (1.22.07.26) this morning. x64 seems broken, but win32 works. Did you manage to support multiple threads? looks alike in taskman - nice work!
runs fluently and stable in medium loads up to approx 60%, getting higher my system starts to shift threads between the cores - managing to "hickup" again.
greetz, Dan
ps: libopenmpt win 64 in xmp works well too as far as i tested

The audio engine is single-threaded and will stay single-threaded for the forseeable future. The only multi-threaded thing going on here is that GUI and audio have their own thread, but that has always been the case.
I can also not confirm that the x64 build is broken, the latest from http://buildbot.openmpt.org/builds/auto/openmpt-win64/ works perfectly here. Is that not the case for you?

Than i suppose there was a "bit" that prevented the audio and gui thread from being processed by different cores up to 1.22.07.20 - because the load is always on one core up to this ver., and the first i tested with real splitting i already wrote before.
The win64 ver. still tells "unhandled exception 0xC0000005 at address ..... occured." right at the start, prior to showing any window or activity.
equal if it is copied to a "normal fitted" ompt folder or to an empty one. win32 runs normally.

There really haven't been any code changes which could have done that - I am rather sure what you are experiencing here is a placebo effect. It is very well possible that a thread is passed on between several cores, but OpenMPT has no influence on that, so it's more likely that some environment conditions changed.

The only reason which I can remotely imagine for those x64 builds on startup would be the recently added check for supported CPU features on those builds. To confirm my suspicion, can you please check if http://buildbot.openmpt.org/builds/auto/openmpt-win64/openmpt-win64-r3755.7z crashes and http://buildbot.openmpt.org/builds/auto/openmpt-win64/openmpt-win64-r3754.7z still works?

Also, if r3755 doesn't work but r3754 still works, please download http://sagagames.de/stuff/mptrack64.7z as well and see if that version crashes. If it does, try running it with the /noAssembly command line switch.

I'll try these tomorrow! But first i like to confirm that i made multiple tests with ...26, ...20 and 3 older versions with the same .it files and watched the core loads in taskman, where ...26 has some 15% more load but divided to 2 cores (of 4),
so maybe the system has a placebo effect but i've got none (but i failed to make double blind study on myself ;-)

G' morning, out there! i just tested the linked versions (clean folder, each) and additionally 3805 from ystd 22:xx.
All win x64 fail - i put up a crash dump.
The win32 3805 still shows the same threading like 3801 (tested with infinite tunnel ;-) ...but in testing several versions around 3700 it shows alterating behaviour now, just "along the mood" of the system - dunno why the present version show this placebo...

Did you try the version from my previous post, and also with the command-line switch? That version contains some potential fixes not found in SVN yet, so these changes are not available on buildbot.

Oh, also, I need crash dumps to be made with the most recent version that I compiled on my system or else I can't do much with them. So please re-download the executable from http://sagagames.de/stuff/mptrack64.7z and generate a crash dump with that version. :)

Argh, I accidentally recompiled that version, so the debuggin stuff won't match again. You'll have to redownload it again for creating a crash dump. :)

Hi, i did and put up 2 crash dumps...
the /noAssembly switch doesn't help it!

Thanks, that's an interesting one. It remains to be seen why it only happens with 64-bit builds, though. For the time being, you'll have to disable the "MIDI Record" check box in the general settings using the 32-bit build, or actually connect a MIDI device. ;)

There should be a new build (r3808) in the same directory as the other ones soon, which should fix the 64-bit issue.

Hi, this workaround works (around ;-),
but there's a message window reporting that the (in fact existing) midi input output dll were missing, wether it is placed in ompt root or plugin dir as the windows says.
giving me 5% more voices than win32

OpenMPT doesn't care where you place the DLL as long as don't change the plugin path in the list of known plugins. Right now, it most likely points to the 32-bit version of the plugin, which you can't use without a plugin bridge. As long as the official plugin bridge isn't done, you must resort to either
1) using external solutions like jBridge
2) Only use plugins of one flavour (32-bit or 64-bit)
3) Make one version of OpenMPT portable so that it doesn't try to share its settings with the other version.

I guess we can mark this issue as resolved then?

Well:
all but one of my five (or more?) ompt installations are portable, the recent builts win32 and win64 both are - the only thing is that i use an ini orig. made with the win32 ver.
But the message says, that in the win64-version's dir the midi i/o dll is missing while in fact it's there - shouldn't it tell 'bout an other dir, if it takes the path from the ini or the registry??

Nope, it has set it's own path wrong as one of the first entries in the ini: "[vstplugins] plugin0=.plugins/midi/midi input output.dll"
i never defined this manually myself,
but now i changed it and the message vanished!

Plugins from the Plugins folder are automatically added when running hte installer. And the installer only comes with 32-bit plugins at the moment. :)