BizHawk is a multi-system emulator written in C#. BizHawk provides nice features for casual gamers such as full screen, and joypad support in addition to full rerecording and debugging tools for all system cores.
More a rough idea for a better Clock Throttle. This differs from standard Audio Throttle, which throttles based on whether the audio driver has eaten up audio samples. This generally works great, however, it fundamentally can't operate with speed increments/decrements, only fast forward/turbo. It also just has the flaw of being imprecise with its throttling, as audio drivers typically don't do better than just eating ~10 ms of samples at a time, and can potentially be much worse, in any case ultimately being very uneven with frame timings. Audio Clock Throttle would work as simply using the core's audio samples as a metric of timing info. Instead of just going with 1 frame = Vsync Den/Num time has passed, simply consider how many samples / 44100 has passed. This can have increments/decrements of time just like Clock Throttle. This also can be understood to just be like Sync To Audio operates with A/V writing, and similarly it wouldn't have pitch issues like standard Clock Throttle has.
Not sure how easy it would be to implement such, throttle class would need to know samples taken from the core in host sound handling (dunno, add callback to host sound manager which gives number of samples to throttle class?). Of course too, it would be nonfunctional if renderSound is false (although such cases presumingly want unthrottling anyways?)
More a rough idea for a better Clock Throttle. This differs from standard Audio Throttle, which throttles based on whether the audio driver has eaten up audio samples. This generally works great, however, it fundamentally can't operate with speed increments/decrements, only fast forward/turbo. It also just has the flaw of being imprecise with its throttling, as audio drivers typically don't do better than just eating ~10 ms of samples at a time, and can potentially be much worse, in any case ultimately being very uneven with frame timings. Audio Clock Throttle would work as simply using the core's audio samples as a metric of timing info. Instead of just going with 1 frame = Vsync Den/Num time has passed, simply consider how many samples / 44100 has passed. This can have increments/decrements of time just like Clock Throttle. This also can be understood to just be like Sync To Audio operates with A/V writing, and similarly it wouldn't have pitch issues like standard Clock Throttle has.
Not sure how easy it would be to implement such, throttle class would need to know samples taken from the core in host sound handling (dunno, add callback to host sound manager which gives number of samples to throttle class?). Of course too, it would be nonfunctional if renderSound is false (although such cases presumingly want unthrottling anyways?)