ares
ares copied to clipboard
ares-emulator
[WASAPI] Audio is desyncing after fast-forward
Using WASAPI driver, after you fast forward the game, and runs in normal speed after it, the audio desync and the sounds comes only after a few milliseconds after it would be. See the issue in the videos below:
Mega Drive core: https://youtu.be/ZeAJaXeGhZs Super Nintendo core: https://user-images.githubusercontent.com/12163923/179130713-5f428e95-638a-4e4b-99c9-0293e7da0eb9.mp4 Famicom core: https://youtu.be/EezrxoWu9Ks
ares v129 Using an updated Realtek Audio driver Windows 10 x64
Can't reproduce and I also have realtek audio on Win10. Perhaps try rolling back the updated oem realtek driver to the one that Windows defaults to.
@Shideravan It might be how it behaves for me as well.
Does Xaudio2 in fast speed sound like, well sound that's fast forwarding. But Wasapi just plays normal and at times "jumps" forward. Like it if you had a player it would be like playing from 0.00 to 0.04 then jumping to 0.08 or something, then play normal awhile then repeat.
Can't reproduce and I also have realtek audio on Win10. Perhaps try rolling back the updated oem realtek driver to the one that Windows defaults to.
I removed the realtek driver and I'm using default windows sound driver now. The problem persists.
@Shideravan It might be how it behaves for me as well.
Does Xaudio2 in fast speed sound like, well sound that's fast forwarding. But Wasapi just plays normal and at times "jumps" forward. Like it if you had a player it would be like playing from 0.00 to 0.04 then jumping to 0.08 or something, then play normal awhile then repeat.
The problem is not related with "audio stretching". The desync mentioned happens after the fast-forward.
I also have another issue related with XAudio2.1: the sound occasionally stops for me (especially when savestating/loadstating). Not sure why this happens tho.
Do you use Dynamic Rate, in that case turn it off. At least it breaks on XAudio2.1 which I learned it wasn't meant for recently.
EDIT: I just got the desync myself and think i recall how i fixed it before. I didn't have audio synchronize enabled, which I recall causes this. So check that it's enabled.
Disabling both options really avoid the issue with XAudio2. But the problem with WASAPI remains yet.
Wait, disabling them avoids the desync in XAudio2, didn't even know there was one?
What i noticed is that XAudio2 seems to behave according to the buffer, so whenever it's "desynced" it just drops or jump forward, so you just hear a "click" or something. But in WASAPI, i will behave like that when the audio is faster than the video. But if the video is faster than the audio, it will just keep on playing and the buffer just expands i guess, until it hits a wall (which seems to be several seconds) where it will resync again.
Though listening to your video example, i can hear the "click" but it seems to just be what causes the delay. I think that can happen as well, and i believe if you hold the window to make the game freeze you can trigger this, it seems to go both ways though, sometimes it causes the delay, sometimes it fixes it.
But it will happen one way or another eventually if synchronization is disabled with WASAPI (in my experience). And it seems to indicate something wrong in the code, as the others audio APIs don't behave the same way.
I cannot reproduce anymore this issue in the most recent version of ares. Probably this was fixed in any point and/or I changed drivers of settings in the reference system used for testing. If the issue return later in any form (or somebody else experience the same problem), we can reopen this issue.