Audio Crackling and Stuttering, Except when Recording

For the past couple of months, I have had a very strange issue in RetroArch. Every 10 to 60 seconds, I get an audio stutter or crackle. Sometimes, it is barely noticeable, and other times, it is massively distracting. I have tried changing every imaginable setting, including the audio latency, the frame delay, the vertical refresh rate, and more. I have noticed that these crackles and stutters often, if not always, coincide with a drop in the estimated screen refresh rate.

I run RetroArch on a 60hz 1080p Flatscreen Samsung TV, manufactured around 10 years ago. I have two monitors. One is that same TV, and the other is a 60hz 4K ASUS monitor. Both monitors receive video signals from the same graphics card, and I switch back and forth between the two by invoking the key-command, “Windows+P” to select “PC Screen Only” when I want to use ASUS monitor, and “Second Screen Only” when I want to use the TV.

I almost exclusively use Retroarch on the TV, but the crackling and stuttering is also present on the monitor, being just as bad if not worse. The PC that I run RetroArch on is certainly no bottleneck, as it is a custom-built gaming PC with the following specifications:

An ASUS ROG Maximus X Hero Wi-Fi AC Motherboard.

An Intel 8700K CPU, de-lidded, with the stock thermal paste having been replaced with liquid metal and overclocked to 4.8 GHz.

A Coolermaster ML240R CPU water cooler.

A Nvidia GTX 1080 TI FTW3 Hybrid Graphics Card.

16GB (2 x 8GB) of Patriot Viper DDR4 Memory running at 3600 Mhz.

1TB of Plextor M.2 Solid State Drive Storage (This is where Retroarch, all ROM files, and anything else relating to Retroarch is running from).

12TB of Seagate BarraCuda Pro SATA Hard Disk Drive Storage.

Two 8TB Seagate Backup Plus Drives, used to back up my entire storage setup.

A NZXT H700i Mid-Tower Case.

Clearly, this PC should not have any technical issues running even the most demanding RetroArch cores, such as Higan-Accuracy, which is what I am using in the video below to run Super Mario World and demonstrate this audio problem. Every time I bring my wireless keyboard in front of the camera, I am either beginning or stopping the screen recording with either “CTRL+F12” or “CTRL+SHIFT+F12” respectively. The first time, I am starting the recording, the second time, I am stopping it, and I go back and forth several times until the end of the video. I could not upload a direct screen recording, since this audio problem only occurs when I am not recording, and I needed to demonstrate how the issue only exists when not using the screen recording software, which is “OBS Studio.”

Whenever I use OBS Studio to record the screen, most, if not all of these crackling and stuttering sounds go away. This is reflected in the frame rate, shown in the top left of the screen, along with other statistics. It becomes apparent that, when not recording, the frame rate fluctuates, usually between around 59.90 FPS and 60.10 FPS, but will occasionally drop to around 59.00 FPS or even as low as 58.00 FPS. When this happens, there is usually a crackle or stutter, and the severity of these sounds is often increased with lower frame rates. After dropping, the frame rate corrects itself to around 60.00, before dropping, and thus crackling or stuttering again, within a minute or even less.

However, when recording with OBS Studio, the frame rate never drops to these low levels. It still fluctuates between 59.90 FPS and 60.10 FPS, occasionally falling outside of these ranges, but never as low as 59.00 FPS, and there are never any audio crackles or stutters, as far as I can tell. I played Super Mario World for about 2 hours with no crackles or stutters, recording the whole time. After I was done, I stopped the recording and deleted the file, which was over 10 GB. Earlier, I couldn’t get through the title screen demo without first hearing at least one crackle or stutter.

It is also worth noting that, when not recording with OBS Studio, this audio problem persists throughout every core for every system that I could find, including NES cores like Nestopia and MESEN and GBA cores like mGBA. I am using d3d11 as the video driver for all cores, however changing it has no effect on this problem. The same can be said for the audio driver, which is currently set to xaudio, and all other drivers. I also disabled rewinds, to little avail. However, disabling all shaders did seem to have an effect, but that is no solution, since not being able to use shaders is a deal breaker for me. Also, the shader that I am using for most cores is not even very resource intensive, that being crt-hylian.slangp. I also use a front-end program, LaunchBox, running in BigBox mode, to launch RetroArch with a specified core and game.

It seems counter-intuitive that recording the screen, which should put more strain on the processor and graphics card, actually fixes the problem of audio crackling and stuttering for me. I think that it might have something to do with how OBS Studio limits the frame rate of programs or alters the way in which the audio frame buffer works. I’m not an expert on those things, so I cannot be certain.

However, using OBS Studio is not a true solution, because while my computer can run it along with other programs without breaking a sweat, lower-end computers may struggle if the users of such computers also encounter this issue, and after every play session, I must delete a massive, multi-gigabyte file or else I will waste valuable storage space on my larger hard drive, which is where I store these recordings, since my solid state drive has far less space, and I have had no issues using the larger drive. Most importantly, since I had to use external software to solve this problem, there is definitely still an issue to be fixed in Retroarch itself, unless I have some setting set terribly wrong.

I have posted a couple of .cfg files, since I use separate .cfg files for each core that I use, one that I use for NES games running on MESEN, and one that I use for SNES games, running on Higan-Accuracy. The settings for these files are similar to each other, and they are both very similar to the .cfg files that I have created for all of the other cores that I use.

Finally, I have posted a video below, recorded with my phone, since I could not use the screen recording software for reasons outlined above, that demonstrates this issue clearly, which the frame rate visible in the top left of the screen. It drops when the audio crackles and stutters, and when I bring the keyboard in front of the camera and press “CTRL+F12,” the frame rate drops and the audio problems go away, only to come back when I bring the keyboard in front of the camera again and press “CTRL+SHIFT+F12.” I then toggle the recording on and off several more times, bringing the keyboard in front of the camera each time I toggle it.

Hopefully these .cfg files and the video will be helpful in diagnosing and solving this problem permanently, and for everyone. I apologize for the somewhat blurry and pixelated video quality with the difficult-to-read statistics, but it should still be legible and useful. The video also looks a bit odd due to the scanline shader being used, which looks bad on video but excellent in person. The sound is mono, and not of the best quality, since I was using my phone’s built-in microphone, but it should still be possible to hear the issues described above. The video is about 5 and a half minutes long, and I suggest that anyone looking to identify or solve this problem watch and listen to this video in full at the highest resolution and frame rate, paying particular attention to the frame rate number at the top left of the screen.

Here are the .cfg files:

NES .cfg File

SNES .cfg File

Here is the video:

Sounds like your CPU is clocking down when not recording, which can cause crackles. Try changing your Windows power plan to High Performance to prevent that. There is a similar power option in the Nvidia control panel you can try tweaking too.

It appears that I have found a solution to the problem. I checked my NVIDIA Control Panel, and “Power management mode” was set to “Optimal power.” My Windows Power Plan was already set to “Maxiumum Performance.” I used MSI Afterburner to monitor my GPU and CPU usage while running RetroArch. What I found was astounding. When not recording, my GPU frequency was running at roughly 400 Mhz with relatively low usage, around 10%. When recording, my GPU frequency nearly quadrupled, reaching almost 1600 Mhz! I changed my NVIDIA Control Panel’s “Power management mode” to “Prefer maximum performance.” Now, my GPU’s frequency stayed at around 1600 Mhz, even when not recording, and the usage seemed to decline to around 2%. Throughout all of this, my overclocked CPU speed of 4800 Mhz stayed consistent.

In short, NVIDIA’s power-saving setting was the cause of this problem, and by changing that setting, which is “Power management mode,” from “Optimal power” to “Prefer maximum performance,” I was able to ensure that my GPU was reaching its fullest potential in RetroArch. Now that this setting has been changed, my RetroArch frame rate stays much closer to 60.00 FPS, never going down a whole FPS again, and there are no more audio crackles or stutters. There are no noticeable video stutters, either.

Nice! I’ve heard of others having the crackling issue fixed by changing that setting. It’s curious since software based cores like Mesen and mGBA don’t really make use the GPU. If you use shaders, those do run on the GPU, but most aren’t very taxing to dedicated GPUs. For whatever reason, my aging 2500k + GTX 970 build doesn’t have crackling issues with the default Windows Balanced and Nvidia Optimal power settings even with a CRT shader. Unless I crank up latency reducing options too high (like frame delay), or try incredibly demanding stuff like Parallel with the angrylion video plugin. But those aren’t improved by changing power settings; they need more hardware grunt.

To be frank, i wouldn’t want to have a global “maximum performance” state on my system, that’s extra heat and waste of power. Thankfully, Nvidia lets you use the maximum performance option in per-application scenarios only if you want.

1 Like