search

pokemon-speedrunning / gambatte-speedrun

Fork of https://github.com/sinamas/gambatte with Pokemon speedrunning-related changes.
GNU General Public License v2.0
94 stars 27 forks source link

WASAPI bugs OBS audio buffer #81

Open hwangbro opened 3 years ago

hwangbro commented 3 years ago

When using WASAPI engine, using any emulator function that pauses emulation (save/load states, load rom, pause, frame step, changing settings) causes audio buffer issues in OBS. After "max audio buffer" reached, I'm still able to hear the game audio and it appears in the audio bar in OBS, but the recording will not contain game audio. Below is an excerpt from my OBS log, the last few lines show the behavior. Using DirectSound seems to fix this issue for me.


21:35:10.884: [Loaded global audio device]: 'Desktop Audio'
21:35:10.884:     - filter: 'Gain' (gain_filter)
21:35:10.896: WASAPI: Device 'Microphone (2- Antlion USB Microphone)' [48000 Hz] initialized
21:35:10.896: [Loaded global audio device]: 'Mic/Aux'
21:35:10.920: adding 42 milliseconds of audio buffering, total audio buffering is now 42 milliseconds (source: Mic/Aux)

21:35:13.438: [game-capture: 'Gambatte'] attempting to hook process: gambatte_speedrun.exe
21:35:14.037: [game-capture: 'Gambatte'] d3d9 shared texture capture successful
21:35:14.054: [game-capture: 'Gambatte'] shared texture capture successful
21:35:33.529: Max audio buffering reached!
21:35:33.529: adding 917 milliseconds of audio buffering, total audio buffering is now 960 milliseconds (source: Desktop Audio)```
entrpntr commented 3 years ago

Possible solution on the OBS side from here:

Some audio devices do not send proper timestamps, and can cause various issues, such as audio desync. Try disabling the device timestamps in OBS by clicking the Gear icon next to your audio source, select Properties, and then uncheck "Use device timestamps."

Not sure if anyone else has run across this issue in GSR (I couldn't replicate it), but googling shows a handful of people have ran into this with OBS, and wrong timestamps seem to be the root cause behind adding to the audio buffer. It's still possible GSR might have some complicity in this behavior somewhere in its WASAPI engine code, given the specific way you're able to induce it.

Since DirectSound has been deprecated for a while and WASAPI is generally recommended, this may warrant a closer look even if the above solution is a successful workaround.