Maintaining 100% Speed Previously Achieved

[vicosku]

Hi all.  I somehow attained 100% speed and an audio latency setting of 1.0 with 0 sound buffer overflows with one of my favorite games on Wednesday.  Thursday morning, I somehow ruined it and speed reduced to 99.92% and audible sound buffer overflows returned every 12 seconds.  I can't figure out why after a lot of reading and experimentation, so I'm hoping someone might have some idea.  I wouldn't care about log statistics if they weren't noticeable in-game, but the sound glitches are definitely distracting and I want to be rid of them after experiencing my prior results.

I've attached some logs.  In the first, I'm just testing an audio_latency setting of 1.0 to see the amount of overflows associated.  In the 2nd, I removed a secondary monitor that was attached via HDMI and also changed my primary output from a VGA splitter and connected directly to a Sony PVM.  I also changed the frame_delay setting from 1 back to my usual setting of 7 for this game via its specific ini.  I believe these are the only changes that were made between tests.  You can see 100% speed and 0 overflows as the result.

After this, I ran 16 more tests trying to verify that it wasn't a fluke and trying to determine what the cause was.  Nothing ruined the 100% speed.  It remained the same even through reboots, and when playing I could hear no sound glitches.  The 3rd log included was the last one I took that day, and even though it shows some sound buffer overruns that time, I wasn't able to notice them in-game.

The 4th log is the next morning when I added a custom monitor line in garou.ini after reading one of Calamity's posts.  It fixed a slight width problem that I've been meaning to fix for a while, and I thought I had achieved perfection with Neo Geo games, but I noticed the sound glitches were back.  I ran another test, and sure enough, performance had degraded to that shown in log 1.  In log 4 I revert the video changes, but it doesn't return performance to 100%.  I've tried a variety of things since then with no luck.

The only changes between 3 and 4 should have been that I put the computer to sleep, woke it up, and tested that custom monitor line.  By comparing the logs, I see that the display device name differs, but 2 and 4 share the same name, so I'm not sure it matters. I should mention that during my tests the previous day I switched back and forth between my two PVMs with no problems.  I also tried Frame_delay settings from 1 up to 7 and audio latencies from 1.0-2.0 since I had been messing with those in garou.ini and garouh.ini previously.  Nothing brought the 100% result back or the low overflows.  Any ideas?  I feel like there must be some solution that can be tracked down.  Below are my system specs, and I've included an unthrottled log that shows the game to be running at 690.91% in case performance plays into this.  If so, I don't know why i would be able to maintain 100% performance for a such a long period on Wednesday through reboots though.

Dell Optiplex 755
e8600 3.33Ghz Core 2 Duo
2 GB PC6400 RAM
ATI HD 4550
Onboard Soundmax Audio with stable <500Hz off target sample rate conversion
WinXP x64
/pmtimer switch enabled
Groovymame x64

Thanks to anyone that took the time to read this.

[Calamity]

Hi vicosku,

This is the typical obscure problem that looks like it has no logical explanation. Sadly, because video drivers are a damned black box all we can do is try to figure out what may be going on under the hood.

How can the exact same modeline produce a different refresh rate with the same card? I can think of two possible causes.

The first one is an unreliable dotclock. We often think about these things as if they were fully deterministic, and hopefully they were. But in real life, at the end of the chain there's an oscillator, that may be affected by things like your room temperature. Some dotclock values may be more consistent than others. Usually all but a few are very consistent. Unfortunatelly it's not possible to know which ones are unconsistent to bypass them beforehand. This 6.63 MHz value may be problematic with your specific card. You can probably choose a different value, higher or lower, that works better with your card, and modify the modeline to use it. This can be easily done with ArcadeOSD, by testing the refresh speed (use key "5"). Once you have a satisfactory modeline, you have to put it into your game specific .ini. Pay attention to this: you must put a modeline in your ini file (yeah, a raw modeline: "modeline "320x224_60 15.61KHz 59.14Hz" 6.62 ..."), NOT a crt_range. To get that modeline, write down the values from ArcadeOSD.

The second possible cause is that a different CRTC (CRT controller) is being used since your day #2 tests. A video card has usually 2 independent CRTCs, which can be mapped to either of the outputs. The video drivers are responsible for doing this, the OS doesn't care. So maybe the first day, due to the specific sequence in which you connected and disconnected your various monitors, say CRTC #1 ended up being mapped to the DVI-D output. Then you turn off the computer, and the next day, when it boots with just the arcade monitor connected, the drivers decide it's a better idea to map the CRTC #2 to the DVI-D output. Now let's think that for same reason CRTC #1 provides slightly different refresh values than CRTC #2. (If this is the reason why you're seeing a different number in the monitor section of your logs, I don't know).

Finally, as you know GM forces the sound to be synchronize with the video refresh when the -syncrefresh option is used (almost always). This removes most sound glitches. The problem is that when you use the -frame_delay option. this sound synchronization is disabled because I still haven't found a way to make it work reliably with this option. The consequence of this is that unless you get an exact figure for the refresh rate (rare) you may have some audio glitches (the ones that are masked when sound synchronization is active). Thus, manually adjusted modelines may be required if you want to get absolutely perfect sound (as suggested above).

[vicosku]

Calamity, thank you for the very detailed reply!  This gives me a lot to work with.