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.
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.
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.
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).
Unless the system is too slow to maintain 100% frame rate, there is no problem.
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.
And in the process destroy the audio/video cycle sync that is the heart of NEStopia.
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.
these sound problems don't exist in e.g. 1.08 on the same PCs that exhibit problems with 1.41
What proof do you have to back up this claim?
