"Sync game to audio" creates motion sututtering (SVN945)

[Gobo]

First of all, hello forum.

 

Now here's my problem; leaving "Sync game to audio" checked creates motion stuttering when playing in fullscreen, vsyncing to 60hz. I have tried about every possible combination of settings but to no avail. Disabling it, of course, gets rid of the stuttering, but then audio screws up quite badly.

 

The best way to test this is to go fullscreen and vsync to 60hz with "Sync game to audio" checked. Make sure your system isn't running anything else in the background that would mess with the framerate. Now load a game with long, horizontal smooth scrolling scenes (Super Mario Land 2's map should do), keep moving left and right (B+pad) till you notice the stuttering, which may happen any time.

 

Gambatte gets this right, not stuttering under normal circumstances, so at least a fix should be technically possible.

 

Thanks for your time and thanks for this great emulator.

[Squall Leonhart]

if anything is messing with your framerate, then im sorry this isn't a vba-m issue even with other things closed.

 

your system is just not capable of holding the emulator at full speed.

[Gobo]

if anything is messing with your framerate, then im sorry this isn't a vba-m issue even with other things closed.

 

Wrong assumption on your part. Nothing is messing with my framerate (I spend quite a deal of time optimizing my system precisely to avoid such problems) and that's why I specifically suggested that people should test this without anything in the background wasting CPU cycles.

 

your system is just not capable of holding the emulator at full speed.

 

Another equally wrong assumption on your part, unless this thing was designed for Crays.

[Squall Leonhart]

sorry, but your issue is just not reproducible on anything over a Athlon 2000.

[Gobo]

Alright. What are the recommended specs for plain gb/gbc emulation without filters or complex scalers? by recommended I mean, fast enough there's no way on earth it will slowdown no matter what. This was tested on a 3.8ghz Intel Pentium 4 with Windows XP Professional SP3 on top. The OS and everything relevant to VBA-M's requirements is up to date.

 

Also "not reproducible on anything over an Athlon 2000" implies God knows how many CPU models thus it'd have been virtually impossible for you to run this test extensively enough to tell for sure. At best it's a "not reproducible on my Athlon 2000" I'd say the problem lies somewhere else.

 

Anyways, if 3.8ghz won't cut it for plain GMB emulation, make it an emergency call for optimization.

[Squall Leonhart]

Does that pentium 4 have HTT?

 

if so, disable it as well as speed stepping. P4 C states are notorious for reduced performance, especially when the code runs efficient enough that most of the time it doesn't need to ramp up the clock rate.

 

the stutter is caused by the application switching HTT threads and switching the thread to active.

 

 

As for my hardware, I had an Athlon 2000 through most of vba-m's development, as well as several Durons spanning 850 - 1300mhz, a mobile Athlon64, Sempron 1250, mobile Core2 based Pentium, and my current i7 920.

[Gobo]

Yes, it has HT, but all it does is make regular application run slower so I keep it disabled. Granted it's not HT getting in the middle.

 

Does VBA-M's sound engine require hardware buffers?

 

A few hours ago I had the opportunity to run the test on a 3.0ghz with similar specs and it too failed. It's worth noting that you may not be able to reproduce the same type of stuttering on LCD screens, specially laptops' which work at fixed rates such as 75hz (60 frames per second "refreshed" 75 times per second would result in natural stuttery movement so it'd be hard to tell them apart)

 

For all I know VBA-M is unable properly sync to 60hz (as I understand it, the gameboy doesn't output at exactly 60hz so there the problem) and then sound to that, so one will always be behind the other and that's where the resync code enters the scene. Normally it's better to resync sound to video rather than video to sound (what seems to be the case here) but in VBA-M neither seems to do the job.

 

Any other ideas? for comparison, Cycle-exact WinUAE, which's far more demanding, can do this properly, and so can Gambatte.

[Squall Leonhart]

Does VBA-M's sound engine require hardware buffers?

 

no, however xaudio on XP only uses DirectSound,

 

need to get a openal enabled build uploaded.....

 

are you using opengl or direct3D?

[Gobo]

I get the exact same behavior regardless of the API.

[Squall Leonhart]

can you get dpc latency tool and run that in the background while playing through.