Oh, that’s really nice 
Thank you for writing that up.
Be wary that some of these options will be changed as of 0.9.2.
Audio input rate is replaced with a more multi-system friendly “monitor display rate” (in video options). This can be used, along with system specific timings to calculate a more appropriate value for audio input rate. I’ve found that a good baseline is 59.95Hz, and for SNES, this becomes ~31960, exactly the value I’ve found for my screen by twiddling. 
The BSV movie handling will be altered a bit as well.
Sounds good. I’ll try to keep these pages updated as much as possible, and I plan to spend some time fleshing out the advanced options that I’m not currently familiar with. Are all of the CLI/cfg flags listed and/or explained anywhere, such as a manpage?
Also, if anyone sees any errors or confusing explanations, please let me know. 
On *nix, the default skeleton config is installed to /etc/ssnes.cfg. Where every option has a small description (except the redundant input ones).
About DSP plugins, there are several, with 5-6 plugs from mudlord. Even has a Qt GUI https://github.com/Themaister/SNES-DSP-plugins
I have a WASAPI external audio driver, but it’s not very stable, and XAudio2 does the job just as well anyways.
This seems pretty great, except for the screenshots. They easily fit in anyone’s browser at full size, so you should make them full size instead of thumbnails.
Hello Themaister,
I have been reading both of your posts in http://board.byuu.org/viewtopic.php?f=3&t=1462
And was wondering if you had any interest in an experimental implementation of what you had said:
Just for reference I am running x86 XP (using DirectSound, generally), but I know yours is multi-platform anyway (which is great philosophy). Like I said I am just wondering about the potential implementation interests of yours about such (other) ways of solving crackling issues. Personally, I would, in all honesty, still be using ZSNES if it weren’t about the lack of both shader support and accuracy, as I like it being able to use vsync without any careful fiddling over there.
While ZSNES does adjust the timer and envelope rates according to the sample rate, it doesn’t actually enforce strict synchronization between the DSP and video output produced by the rest of the emulator. It simply emulates enough samples to fill the output DirectSound buffer, 256 samples at a time, every frame. Thus, the DSP is only frame accurate, and the timing is completely dependent on the host system.
Doesn’t seem like an approach we could employ in SSNES indeed. 
I tried once to implement dynamic resampling, but it fell flat as there is no way you can reliably guarantee that you’ll never block, but never underrun as well, and at the same time not incurring large fluctuations in audio pitch (+/- 1% might be acceptable, but probably not much more). To give more headroom, you’d need to employ a lot more latency, and that is an unacceptable tradeoff too.
One possible approach too is aggressive time stretching, however, that reduces audio quality, and is probably rather CPU intensive. kode54 might have some solution there though.
I think the current approach works rather well though, not perfect, but hey. Display rate setting in video lets you tweak a bit, and replaced audio input rate to work with more libsnes implementations.
While it could be technically possible to detect screen refresh rate automatically and adjust it to near perfection, that approach is typically not reliable enough. There are several cases where it is simply reported wrongly, or not accurate enough.
SoundTouch is actually quite fast, but it does incur some quality loss, even if it may not be so noticeable if you only do 1-2% time stretching and compressing. And you can adjust the factor in semi-real-time.
Being the layman-in-the-domain person I actually am, I am not really getting getting how, practically speaking, ZSNES gets to differ from a real SNES in its audio output. Are you implying something akin to a higher latency, or else, a general lack of synchronization?
Sorry for the interference here; it is just that I am not familiar with most of the terms you have used. ::embarrassed::
General lack of synchronization.
The 5A22 to SPC-700 timing is also horrid, too. It’s a ratio of OPCODES to OPCODES, not cycles to cycles.
And, how intense is this general lack of synchronization? Is it something noticeable through normal human senses?
Does it affect all games? etc.
It may not be noticeable, but it can certainly add up to breaking timing sensitive games.
Just out of curiosity, which, or what types of, games, could be considered as “timing sensitive?”
/consider this as a general chat. I am hoping not to bother too much with such questions. But I cannot tell as I have a significant lack of clues since the people I am talking to are not in front of me!
Earthworm Jim 2. Streams the sound effects to the SPC-700 as they play. If it doesn’t lock up by the time you make it to Lorenzen’s Soil, the second level, count yourself lucky.
Oh. By “breaking,” were you meaning “freezing?” Or, some other very noticeable thing, such as audio disappearance?
In other words, if there was no lock up, then one could assume that pretty much everything (as far as an avoidance of a significant, noticeable lack of synchronization is concerned) went as would have went on the real thing, right?
If you are interested, the only games I own are Metroid 3, The Triforce of the Gods, and, as has been mentioned in that other thread, Little Magic. In the former two, since I never experienced any freezes, I am assuming I received about the same (read: original; intended) experience than I would have if I had been playing on the real hardware set.
I see my last post disappeared, so I’ll repost it.
Some games, particularly those from Square from back in the day, would have incredibly inconsistent sound effects. They would never play the same each time you hear them. All due to improper synchronization between the 5A22, the APU, and the DSP.
Yes. It appears there has been some trouble with the forums here, recently.
It’s good to know that, while ZSNES does not work correctly with a large proportion of games, it seems to do with some others.