Input latency issues with Hyperspin? Use multithreading

[Chainsaw]

I'm posting this because it may help others.

A while back I posted here about issues I was having with R-Type - input was sometimes delayed, and sometimes the input would continue being read after I'd released the controls. I got great support on this forum. I ended up running a load of tests and it seemed to go away after a while.

What I only realised today was the issue was caused by HyperSpin. You see, when I had my R-Type issue, I had just starting building my cab and it was my first test with the software. Since then, I've not been using HyperSpin as the cab has been in pieces - I've ran all tests with MAME from the CMD line. Now I'm nearing the end of the project, I'm finalising the software, and low and behold, launching MAME in HyperSpin is causing input issues on every game I try.

So I done the obvious - I turned off HyperLaunch, and launched MAME directly from HyperSpin. I turned off all visual effects, except videos, in HyperSpin. I turned off Input Delay in HyperSpin (which is needed to help choose the game, else the wheel goes too fast). None of these things helped.

To be clear here, the problem I was having was not slow-down in the emulator, I was running 100% all the time. It was input problems; buttons / joysticks not being registered, or activating too late, or acting like they'd been pressed-down longer than they had been. I tried a variety of old / easy to emulate games like Bubble Bobble, DKong, Frogger, and this affected all of them.

If HyperSpin was running in the background, I had this same issue when running MAME from the CMD line. However, killing HyperSpin in Task Manager resolved the issue every single time. The difference in control was immediately obvious.

The solution I have, which may help others if they encounter it, is to simply turn on multithreading in the MAME config. Issue was resolved immediately. I find this odd as I never dropped below 100% emulation speed, there was no slow down in the game itself, just in reading the inputs (both through an USB IPAC and a USB keyboard). I'm running a reasonable X4 Athlon processor, it's only a few years old so more than enough for emulating the games I am interested in.

I understand multithreading may cause synch issues when emulating? I don't believe you can specify which core to run a process on until after it is running (via Task Manager) so unless I can tell HyperSpin or MAME to use exclusively another core, I'll stick with multithreading as the solution.

Anyway, I thought I'd post this, as it may help others.

Thanks 

[bulbousbeard]

Turning on multithreading is confirmed to introduce bugs in MAME. There's a reason why the devs turned it off by default. It simply doesn't work predictably.

And Hyperspin is a piece of ---steaming pile of meadow muffin---. I just roll my eyes whenever someone uses it and then complains about problems. It's a horrible, trashy program. It has one job, and it can't even do that competently. Nobody serious about actually playing games would even use Hyperspin. It's a resource hog, it's confirmed to still use CPU even after it launches a game, it seems to introduce erratic behavior in the programs it launches, its Flash videos are cheesy and tacky, it doesn't have proper support for rotated displays. It blows.

[krick]

Is there a clean lightweight MAME frontend that works well on an arcade monitor?  The first frontend I really used was MAMEWah and it was very difficult to setup and configure.  Then many years later I tried Hyperspin and I have many of the same complaints as you.

[ufoufo512]

I messed up my AdvanceMenu setup on Groovy Arcade Linux and re-installed Groovy Arcade from the latest beta. I chose Attract Mode as front-end and I must say I am very happy with it. It has learning curve with configuring  and I am nowhere done yet but initial impressions are very good. The things I like about it:
* Supports 15 KHz
* Supports both horizontal and vertical orientation
* Configurable filters and skins with ready made customizations
* Supports MESS/UME softlists. This is huge plus to me. For example instead of smb.zip you see Super Mario Bros.
* Configuration possible straight inside the frontend, no need to edit configuration file and then restart frontend.

I am no expert by any means and still have a lot to learn using Attract Mode but so far it seems to fill every need I have for a frontend.

Edit: And it is cross platform

[haynor666]

Every frontend needs some time to understand it's configuration even Hyperspin. For me MAMEWAH works great. Very light, fast and easy to use.

[Psicosis]

Can multithreading be enabled on a per game basis? I dont really want to enable it in the mame.ini because of everyone saying how it will cause problems.  Last night i was testing some games and Toobin was running at like 40% horribly bad so I turned on multithreading and it ran at 100% the whole time. It also seems to fix the sound skipping on the old school vertical games like dk and frogger.

[bulbousbeard]

Multithreading can be enabled on a per-game basis with different MAME inis.

It's my frontend, so I'm biased, but I will stand by the statement that Big Blue is by far the easiest frontend to configure. There's really nothing to it. It's Windows-only, though, so if you're on Linux, don't bother.

https://sites.google.com/site/bigbluefrontend/

[Chainsaw]

Another option, and one I'll tinker with next week, could be assigning a specific core to MAME instead of it running on the same core as HyperSpin:

c:\windows\system32\cmd.exe /C start /affinity 2 c:\mame\groovymame.exe

This will put it on core 2. Number is hex, so 1=core 1, 2=core 2, 4=core 3, etc.

Personally, I like HyperSpin. Of all the FEs I've tried, I think it looks the best. Turn off all the effects and simply keep the per-game theme and video, I find it a nice clean interface with the right feel.

[sean_sk]

Just a couple of questions to the OP in regard to their latency issue:

Do you happen to be forcing v-sync on at all? Either through drivers, GM or otherwise? Are you running any keymappers?

[Chainsaw]

I'm not forcing anything I know of. I was running GroovyMAME with a standard config, and the issue occured with both ddraw and d3d. I didn't change vsynch as I understand Groovy handles everything for you.

Regarding keymappers, I think HyperLaunch can do that, but I disabled HyperLaunch and still had the issues. Simply leaving HyperSpin running in the background and launching Groovy via a command line still resulted in the same latency / lag issues, both through the ipac and a USB keyboard.

When I have the cab home and setup permanently, I'll see if I can run record a 60fps video to show the issue. It was really extreme. I'm not talking an extra frame or two of latency, I'm talking about playing Bubble Bobble, pressing (and releasing) Jump, nothing happening, then something like 400ms later the character would do a double jump.

My BIOS is setup as defaults, there's nothing strange going on there.

I had this exact same issue, on the same PC hardware, using a JVSPAC before going the IPAC route, so it wouldn't appear to be a keyboard encoder issue. And if it was a single CPU core being maxed out (ie HyperSpin using resources, as it is still running in the background) I'd have expected to have seen the issue with emulation slowdown, not just I/O slowness.

As I say, if I can I'll get a video done, and I'll setup dual monitors so I can monitor system resources to see what the CPU usage is.

It may be worth running a test with regular MAME as well, but in fairness if this issue is just happening to me, it all seems somewhat academic and not worth investigating.

[sean_sk]

Have you tried posting in Hyperspin forums about it? I've been using HS for a couple of years and haven't heard of this before. It's not to say it isn't possible, just unusual. I tried searching HS forums to see if anyone else has had this. Couldn't fiind anything, but then again I never was a good forum searcher.

The other thing is you mentioned, that multithreading fixed it. Are you running Win XP? I seem to remember years ago Athlon X2's having issues in XP and AMD released the Dual Core Optimizer software. I know you have an X4 so more than likely it's not got anything to do with it, but just covering bases. Also just wondering if there is another underlying issue, like refresh rates.

Have you tried another OS like Win 7?

[sean_sk]

Double post

[Chainsaw]

I tried searching the HS forum as well, and I didn't find anyone else with the same issue.

I've only tried XP. I'm running as barebones setup as I can, just a base XP installation with minimum processes running; I'd need to check but I've not added any updates, it's possible it's pre-SP1. And to state the obvious, I may well have found installing all the XP updates would have resolved the issue.

I'll have the cab at home next week so I'll be able to run some tests. I'm interested why this is happening.

[sean_sk]

I'll have the cab at home next week so I'll be able to run some tests. I'm interested why this is happening.

Yeah keep us posted. I'm very interested as to why this is happening as well.

[Calamity]

I'm posting this because it may help others.

Hi Chainsaw,

Thanks a lot for your post. First, I must say I have no clue why multithreading is fixing your specific issue...

Regarding multithreading in GroovyMAME, please check this:
http://forum.arcadecontrols.com/index.php/topic,137090.msg1414592.html#msg1414592

Multithreading implementation in GM is different from the one in MAME. When it works fine (most of the time) it introduces no issues to emulation, and it is the only way to achieve proper triplebuffering. That's why people are finding out that enabling multithreading in GM magically brings many games back at 100% speed. This is the typical case of vertical games with too many lines to run at 60 Hz.

The multithreading option was enabled by default in old versions of GroovyMAME, back when MAME had it disabled. Later versions of MAME started to enable it by default, so we kept it enabled. At some point people started to complain about vanilla MAME multithreading being flawed (as it is indeed) and they disabled it again.

So we also disabled it, mostly to follow the trend. And we warned people to enable it manually if they wanted triplebuffer to work. Obviously this warning was lost like tears in the rain and dozens of people started to complain about slowdowns, etc. So maybe we should have kept it enabled after all.

Honestly there were some good reasons to disable multithreading. In general, it makes GM somewhat unstable upon dynamic mode switching and lost focus events (alt-tabs, accidental windows key presses, etc). It also simply makes GM crash with multi-screen emulated systems (if you configure them to actually use more than one screen), but this was solved by GM itself disabling multithreading in this situation. And in very, very, very rare cases the synchronization between threads failed for some unknown reason and it made everything run at full speed.

The fact is, if multithreading works fine for you, chances are you can safely keep it enabled. This happens in the vast majority of cases.

Finally, there was an additional reason to disable multithreading, that connects with the OP's topic: the fact that many people keeps insisting on using HS with GroovyMAME. When you have the slightest understanding on the risks of doing something delicate like multithreaded video rendering, there's no need to persuade you about the type of frontend you must look for: you'll go for whatever is closer to a console command line. Does anyone remember the days when we closed all unnecessary programs when doing something real-time critical like burning a CD? To make things even worse, HyperLaunch seems to be configured by default to hook the escape key and close the MAME process on its own... what a convenient feature don't you think? Do this to a process running multithreaded video and disaster is guaranteed.

[bulbousbeard]

MAMEdev's official recommendation on that option is to disable it, and there are now reports that even numprocessors auto causes problem with certain drivers.

Even 64bit builds have a few bugs that aren't in 32bit builds.

The most bulletproof MAME configuration is numprocessors 1, multithreading 0, and a 32bit build, sad to say.

[Chainsaw]

That's a great explanation on the history, thanks Calamity. And thanks BBBeard for that. I've set multithreading to 0 and numprocessors to 1 as suggested. This immediately re-introduced the input latency (I'll get a video sorted eventually).

So here's what I've done. I'm nearly there, I just can't get this working with HyperLaunch yet, I'll look at that another day.

The previous command line I wrote to set affinity only works in Windows 7 (and maybe Vista?) so to get in XP, I needed to work it out.

Firstly, you need pstools:

http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

I run MAME on the G drive, so for my own sanity, I extracted the pstools zip to g:\pstools

My MAME.exe (which is actually GroovyMAME) is in g:\hyperspin\emulators\mame

Inside the mame folder I created a batch file, called it psexecmame.bat, which contains one line.

g:\pstools\psexec -a 2 cmd /c g:\hyperspin\emulators\mame\mame.exe %1

The -a is affinity, so I'm running on core 2. %1 is needed as the parameter you're passing mame (ie the rom).

In HyperHQ, I set the MAME wheel to Execution: Normal (instead of HyperLaunch).

Then set Executable to the batch file created above.

Voila, it's working Input latency is gone, MAME is running exclusively on core 2, while HyperSpin seems to always run on Core 0. I'm going to run some tests tomorrow, shelling directly into HyperSpin and assuming that stays on Core 0 as default.

[bulbousbeard]

Hey Chainsaw, if you ever get time and don't mind, could you tell me if you get the same input latency with Big Blue?

https://sites.google.com/site/bigbluefrontend/

I also have an option to override the Escape key behavior to kill the process (for emulators like M2 that don't close when you press Escape), and I'm wondering if it works okay on your setup. My implementation isn't the same as Hyperspin's, and it seems to work well on my machines, but the testing on it's been limited.

There's a video that explains the option here:

[xga]

Hey Chainsaw,

How did you go with your tests?  Is Hyperspin staying on Core 0 constantly?  This seems like a great workaround if so!

Cheers

[Chainsaw]

I've ran some more tests, but not filmed anything yet. HyperSpin runs on all cores, and I don't believe I can set it's affinity as I'm shelling into HyperSpin (rather than Explorer).

However, with GroovyMAME running on a fixed core as described above, I've had literally no problems at all. It's been so flawless in fact, I've stopped messing around and now I'm simply playing games on the cab 

So while I'm unable to force HyperSpin to a core or two, and keep MAME completely seperate, simply moving it off core 0 seems to have resolved the issue. I'm very happy with the solution

[Chainsaw]

Well, I decided I wanted to have a little website showing my MAME stats. This lead me to looking at HyperLaunch again, as that keeps stats (time and games played, that kind of thing), but from what I could make out, I couldn't really get those same stats out by running a batch file through HyperLaunch.

So right now I'm looking at this program:

http://www.koma-code.de/index.php?option=com_content&task=view&id=88&Itemid=93

You can define the affinity for programs in a profile, and I think set the program to launch at Windows startup. So I can preset MAME to a core, and this program should handle it fine. I should even be able to restrict HyperSpin to keep it entirely seperate from the MAME core.

And that way, I can go back to HyperLaunch, get the stats from that, and a write a little program to parse them and generate some HTML.