View Issue Details

IDProjectCategoryView StatusLast Update
0000481OpenMPTFeature Requestpublic2014-03-10 11:16
ReporterDanH Assigned Tomanx  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Platformx86OSWindowsOS Version7
Product VersionOpenMPT 1.22.07.* (old testing) 
Target VersionOpenMPT 1.23.01.00 (upgrade first)Fixed in VersionOpenMPT 1.23.01.00 (upgrade first) 
Summary0000481: Sound stutter on weaker machine
Description

(where weaker machine is an dual core atom 1.8 Ghz with 4 GB Ram)

since the update from 1.20.x to 1.22.x
i experience more stuttering from overload than before. Some ITs using > 150 active channels (saga - infinite tunnel, sphenx - bubbles) and some only around 60 to 90 (zanoma - world of peace) tend to stutter more than before.

Steps To Reproduce

It's a sort of elite problem, 'cause i use ompt with 96 kHz, 32bit, 8 tap HQ resampling, with digital out.

i tested different settings and found out it runs best with general or device specific system driver. All other: DX, ASIO, WDM are slower or have more timing problems.

Finally i had to limit the sampling rate to 88.2kHz and polyphonie to 96 (bubbles) or 128 (all other tested).
(Yes i hear a difference, and no i cannot discriminate more than 40 channels, and no i don't believe more than 128 channels are really usefull, since every soft channel needs add. mixing calc.s and finally adds a bit noise)

But I'm a bit amused that a machine with 2x1.8 GHz cannot handle 256 voices ("400MHz") Even if it's double the normal sampling rate, and double the normal resampling effort, pi times thumb 1x1.6 GHz should row the boat...

Additional Information

it seems that the main difference is, that in the 1.20 series the player code can "borrow" cpu time, making the ompt gui freeze occassionally but keeping gapless playback. While with the new timing style tracker and gui have more priority.
I guess that's intended for studio use with ompt as timing source.
But is there a possibility to switch behaviour (and add this switch for real weaker machines), or is there another depency - the now independent player code?

TagsNo tags attached.
Attached Files
crash.zip (13,171 bytes)
crash-plain.zip (12,227 bytes)
crash-noAssembly.zip (12,082 bytes)
Has the bug occurred in previous versions?all 1.22.x
Tested code revision (in case you know it)1.22.04.00 - 1.22.07.16

Activities

Saga Musix

Saga Musix

2014-02-08 14:32

administrator   ~0001488

Last edited: 2014-02-08 17:11

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

DanH

DanH

2014-02-08 21:02

reporter   ~0001489

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.

Saga Musix

Saga Musix

2014-02-08 21:34

administrator   ~0001490

<blockquote>Cpu - so an Atom is worse than a P2?</blockquote>
Well, not directly of course, but you get less "bang for the MHz", i.e. an Atom CPU running at 1 GHz might seem much slower than a different type of CPU running at the same rate - similarly to Celeron processors.

<blockquote>Just a silly question: update and boost are for both the player code, and the gui?</blockquote>
The boost setting only boosts the audio code, since that's the only code that's critical. The update interval affects the number of buffers into which the latency is divided, and this directly translates into a GUI update interval. Manx will shed some light on this and how it will be changed to work in the future in an upcoming comment.
Regarding the VU meter setting, this is really only applied to the VU meter since all the other "expensive" GUI parts (such as the pattern editor) are updated at much more coarse intervals anyway, i.e. even if the update interval is 1ms, the patterns are never redrawn at this crazy interval, they are redrawn at most once per row.

manx

manx

2014-02-08 22:07

administrator   ~0001491

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?

DanH

DanH

2014-02-09 09:11

reporter   ~0001492

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...

Saga Musix

Saga Musix

2014-02-09 12:01

administrator   ~0001493

Last edited: 2014-02-09 12:31

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.

DanH

DanH

2014-02-09 12:40

reporter   ~0001494

Last edited: 2014-02-09 12:47

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
Saga Musix

Saga Musix

2014-02-09 13:52

administrator   ~0001495

<blockquote> 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?</blockquote>
That is exactly the current problem of the int filter: The filter should be clipped to double the input range, however due to some misunderstanding of the code, it is clipped to a completely different (wider) range. There shouldn't be any difference between .16 and .19, though, as far as I'm aware.

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

DanH

DanH

2014-02-09 19:54

reporter   ~0001497

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)

Saga Musix

Saga Musix

2014-02-09 19:58

administrator   ~0001498

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.

manx

manx

2014-02-09 20:47

administrator   ~0001499

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.

Saga Musix

Saga Musix

2014-02-21 11:04

administrator   ~0001550

Reminder sent to: DanH

Can you check the new settings described in manx's latest comment?

DanH

DanH

2014-02-22 08:24

reporter   ~0001551

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.

DanH

DanH

2014-03-01 13:09

reporter   ~0001556

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

Saga Musix

Saga Musix

2014-03-01 13:17

administrator   ~0001557

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?

DanH

DanH

2014-03-01 15:58

reporter   ~0001558

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.

Saga Musix

Saga Musix

2014-03-01 16:23

administrator   ~0001559

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?

Saga Musix

Saga Musix

2014-03-01 16:51

administrator   ~0001560

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.

DanH

DanH

2014-03-01 19:14

reporter   ~0001561

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 ;-)

DanH

DanH

2014-03-02 08:04

reporter   ~0001563

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...

Saga Musix

Saga Musix

2014-03-02 08:07

administrator   ~0001564

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.

Saga Musix

Saga Musix

2014-03-02 08:11

administrator   ~0001565

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. :)

Saga Musix

Saga Musix

2014-03-02 10:12

administrator   ~0001566

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. :)

DanH

DanH

2014-03-02 12:04

reporter   ~0001567

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

Saga Musix

Saga Musix

2014-03-02 12:11

administrator   ~0001568

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. ;)

Saga Musix

Saga Musix

2014-03-02 12:21

administrator   ~0001569

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

DanH

DanH

2014-03-02 16:29

reporter   ~0001570

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

Saga Musix

Saga Musix

2014-03-02 17:17

administrator   ~0001571

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?

DanH

DanH

2014-03-02 19:12

reporter   ~0001572

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??

DanH

DanH

2014-03-02 19:23

reporter   ~0001573

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!

Saga Musix

Saga Musix

2014-03-02 19:32

administrator   ~0001574

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

Issue History

Date Modified Username Field Change
2014-02-08 14:18 DanH New Issue
2014-02-08 14:32 Saga Musix Note Added: 0001488
2014-02-08 14:32 Saga Musix Assigned To => Saga Musix
2014-02-08 14:32 Saga Musix Status new => feedback
2014-02-08 17:11 Saga Musix Note Edited: 0001488
2014-02-08 21:02 DanH Note Added: 0001489
2014-02-08 21:02 DanH Status feedback => assigned
2014-02-08 21:34 Saga Musix Note Added: 0001490
2014-02-08 22:07 manx Note Added: 0001491
2014-02-09 09:11 DanH Note Added: 0001492
2014-02-09 12:01 Saga Musix Note Added: 0001493
2014-02-09 12:21 Saga Musix Assigned To Saga Musix =>
2014-02-09 12:26 Saga Musix Note Edited: 0001493
2014-02-09 12:31 Saga Musix Note Edited: 0001493
2014-02-09 12:40 DanH Note Added: 0001494
2014-02-09 12:45 DanH Note Edited: 0001494
2014-02-09 12:47 DanH Note Edited: 0001494
2014-02-09 13:52 Saga Musix Note Added: 0001495
2014-02-09 19:54 DanH Note Added: 0001497
2014-02-09 19:58 Saga Musix Note Added: 0001498
2014-02-09 20:47 manx Note Added: 0001499
2014-02-11 12:39 manx Assigned To => manx
2014-02-11 12:39 manx Status assigned => feedback
2014-02-21 11:04 Saga Musix Note Added: 0001550
2014-02-22 08:24 DanH Note Added: 0001551
2014-02-22 08:24 DanH Status feedback => assigned
2014-03-01 13:09 DanH Note Added: 0001556
2014-03-01 13:17 Saga Musix Note Added: 0001557
2014-03-01 15:58 DanH Note Added: 0001558
2014-03-01 16:23 Saga Musix Note Added: 0001559
2014-03-01 16:51 Saga Musix Note Added: 0001560
2014-03-01 19:14 DanH Note Added: 0001561
2014-03-02 07:47 DanH File Added: crash.zip
2014-03-02 08:04 DanH Note Added: 0001563
2014-03-02 08:07 Saga Musix Note Added: 0001564
2014-03-02 08:11 Saga Musix Note Added: 0001565
2014-03-02 10:12 Saga Musix Note Added: 0001566
2014-03-02 12:02 DanH File Added: crash-plain.zip
2014-03-02 12:02 DanH File Added: crash-noAssembly.zip
2014-03-02 12:04 DanH Note Added: 0001567
2014-03-02 12:11 Saga Musix Note Added: 0001568
2014-03-02 12:21 Saga Musix Note Added: 0001569
2014-03-02 16:29 DanH Note Added: 0001570
2014-03-02 17:17 Saga Musix Note Added: 0001571
2014-03-02 19:12 DanH Note Added: 0001572
2014-03-02 19:23 DanH Note Added: 0001573
2014-03-02 19:32 Saga Musix Note Added: 0001574
2014-03-02 19:33 Saga Musix Status assigned => resolved
2014-03-02 19:33 Saga Musix Resolution open => fixed
2014-03-02 19:33 Saga Musix Fixed in Version => OpenMPT 1.23.01.00 (upgrade first)
2014-03-02 19:33 Saga Musix Target Version => OpenMPT 1.23.01.00 (upgrade first)