Home Page Forums Other Emulator Message Boards Nestopia Nestopia 1.41 unofficial release

Hi,

The choppy sound issue was my damn sound card as suspected (I finally had a chance to test with my onboard one). Sound is perfect. However, input lag is still very evident in v139+ with v-sync on (only). Found v109 in my archives and I have no issues with sound or input lag (in case anyone still has these issues). Yay!

Mike

Tried everything mentioned in this thread, and I still get the odd sound desync (randomly occurs, not sure what's causing it). Is there a known fix for this yet? I'd rather not go back to VirtuaNES because it has some pretty nasty input lag issues in some games, but the sound desync is REALLY killing it for me.

When it does happen, it takes some time before it really starts to become obvious, as it's slowly but surely de-syncing.

EDIT: Just saying, I'm not experiencing any "choppy" or "scratchy" sound problems, just the random desyncs.

What are your system specs?

Sorry for the late reply, but here are my specs:

Operating System: Windows Vista Home Premium

Card name: Intel(R) G45/G43 Express Chipset

Processor: Intel Pentium Dual-Core E5200 (2.50Ghz)

RAM: 4.00 GB

The emulator "runs" perfect, it's the audio I'm having issues with.

I've watched the plethora of replies here about people desperately trying different drivers and hardware configurations and Nestopia settings to try to get rid of sound skipping and/or input lag. I figured it was finally time for me to clear some things up.

As of Windows Vista, DirectSound isn't what it used to be. It is no longer hardware-accelerated, but is instead emulated in software in the audio driver. It looks like Microsoft deprecated DirectSound with Vista because it had so many problems and limitations and was so difficult for programmers to get right (as evidenced by Nestopia), but of course they had to still support it through emulation for legacy compatibility reasons.

Any programs written using DirectSound need to provide a dedicated background thread to continuously supply new audio data to the DirectSound playback buffer to avoid skips or breaks in the audio playback. FCEUX is written this way (go look at its source code), but Nestopia is not. Nestopia does all the DirectSound work on the main emulation thread, which sets up an unpredictable race condition between the main emulation loop and the audio playback buffer. On some systems the main emulation loop is fast enough and the DirectSound emulation in the audio driver is fast and accurate enough that everything mostly works, but that's not the case for most systems. On most systems you get sound skipping (as the main emulation loop can't keep up with the DirectSound playback buffer), input lag (as the main emulation loop gets held up), or some combination of the two.

There are only two ways to fix this probem in Nestopia:

1) Do a significant re-write of Nestopia's audio stack to offload all the DirectSound audio buffer stuff to a background thread, and create an intermediary audio buffering system, very similar to what FCEUX does.

2) Do a significant re-write of Nestopia's audio stack to use Microsoft's new XAudio API instead of DirectSound. XAudio's API set is designed to eliminate exactly this kind of problem, and the driver support should be much better for it.

Either way, it's a non-trivial change to Nestopia's source code, and one I haven't had the time to implement. I still have the idea at the back of my mind and one of these days when I finally have the time I intend to do a rewrite (probably using XAudio) to fix these problems permanently.

If you are lucky enough to get my unofficial Nestopia release (or any previous release) working smoothly, than just consider yourself lucky. But if you run into sound skipping or input lag problems, then my advice to you is to stop trying to muck with priority settings or driver versions or hardware configurations because ultimately none of it will help. The flaw is in Nestopia itself, and it's nearly impossible to predictably work around. For the time being, you are best off using FCEUX or some other NES emulator that doesn't suffer from these problems.

Good to know, c0d3h4x0r! I'm looking forward to a new release! Take your time.

Wrong. Yes, DirectSound was rewritten in Vista, but the results are that in the normal case it's significantly more reliable and breaks up less.

There are tens of thousands of games, emulators, and audio editing/production programs which use DirectSound and show no audio drama on Vista/7 without the use of a separate thread. This includes MAME/MESS, FBA, Raine, ElSemi's Model 2 emulator, bsnes, pSX, and pretty much anything else you might have played.


Unless the system is too slow to maintain 100% frame rate, there is no problem. All the programs cited above show this principle quite nicely.


And in the process destroy the audio/video cycle sync that is the heart of NEStopia.


This might fix it by accident, but the real problem is simply that there is a bug in recent versions of NEStopia. This is proven by the fact that these sound problems don't exist in e.g. 1.08 on the same PCs that exhibit problems with 1.41.

That said, the part about "stop fiddling with NEStopia, you can't fix it" is true. Use an older version of NEStopia or some other emulator (MESS runs most NES games very nicely nowadays and it's on this same forum).

Not if you have a buggy audio driver, which has proven to be the cause for the majority of people who have hit this issue.

Have you examined the source code for ALL of those? This is quite a sweeping claim to make, especially coming from someone who has spent all of... what, 5 minutes?... looking into this problem.

I've looked at source code for many other emulators, and they mostly do it the way FCEUX does it (e.g. the way I've described).

Wrong. The issue here is the correctness of the DirectSound ring buffer playback implementation inside the audio driver. Some drivers (specifically a lot of Creative Labs' drivers) get it wrong, causing the lock/write calls to the buffer to stall and/or reporting incorrect information back to the application about the current state of the buffer. Both problems can cause audio skips regardless of how fast the rest of your system is.

Absolutely wrong. Creating a dedicated background thread that pulls audio data out of a software buffer and jams it into the DirectSound playback ring buffer in no way destroys audio/video sync. All it does is (1) eliminate buffer contention, and (2) guarantee that the DirectSound buffer never gets starved for data due to a momentary hiccup in the performance of the main emulation thread.

What proof do you have to back up this claim?

As it happens, yes. I've looked at the source code for pretty much every source-available emulator out there at one time or another, and fully-threaded audio is generally rare (except for ones still using MMIO/WaveOut where it's a really good idea).


Yes, I know. I programmed the audio for one of the early PC games to support the SB Live. Great hardware, the driver team should be shot.

But seriously, the reason DirectSound is done in software in Vista/7 is exactly to eliminate those problems. The software DSound doesn't misreport buffer positions or get the units wrong or the number of other things I've seen "in the wild" in driver implementations. I've never seen a problem with it - there may *be* one, but on balance it's miles ahead of the previous situation with IHV drivers.


In the case where you don't mean running the entire APU on up on a separate thread, yes, that can work, although ideally you'd want the emulation running a frame or 2 ahead of the audio thread to ensure you always have buffer if a hiccup occurs.


1) The complaints didn't start coming in until around 1.35ish, and 2) users having them have posted that rolling back to older versions did fix the issue.

At least we agree on something :-)

Actually, the software DSound does misreport buffer positions or take an abnormally long time to return from the app Lock()ing the buffer, when using certain buggy audio drivers. I experienced it myself on the integrated audio on my previous motherboard, with Windows 7 amd64 RTM.

Yes. All I'm suggesting is that instead of the main emulation thread asking "how much room is there in the DSound buffer?" and fetching that much audio from the emulation and jamming it into the DSound buffer, it should instead just ask a software buffer implementation "how much data should I give you right now to more or less keep feeding you at the same rate you are consuming?", jam that amount into a software buffer (no contention), then the background thread retrieves data from that buffer and feeds it into the DSound ring buffer. That's essentially what FCEUX does, and it works great.

I've diff'ed the source code going back to before 1.35, and I've never found anything that looks like it should cause or impact this issue.

Unfortunately, I do not have any audio hardware at this time that exhibits this issue under Windows 7, so I am unable to further analyze this problem myself.

EDIT: I see that an Audigy SE board is reported to exhibit this issue, and I also see that Audigy SE boards are under $35 US on newegg.com. Can someone please confirm that this Audigy SE board causes the audio problem with Nestopia using the latest drivers available from Creative Labs? If so, I'll order one and see if I can get a repro.