Audio stutters/dropouts only in OBS recordings

[Thebigcheese]

I am driving myself a little crazy trying to troubleshoot this one, so I thought I'd see if anyone here has any thoughts or ideas. I recently picked up an Audient EVO 8 as a nice general use interface, but in particular, I want to use it in conjunction with OBS to record weekly D&D sessions. I've been doing that for about a year with various other interfaces and the like and not had any problems, but for some reason, when I stream/record with this interface, I get short (like maybe a few milliseconds) stutters/dropouts every so often. I have attached a log file of my last test and in that one, these stutters occur roughly every 5 minutes or so (actually at 5:07, 10:01, 14:35, 15:31, 22:43, 27:37, and 31:07 in video time, not time of day). In other cases, it has been maybe once every 15 minutes or so. There isn't a ton of consistency to it. The encoder settings in the log are what I use for recording non-D&D things, but for D&D, I actually use lower quality settings so I can stream it instead of having to upload to YouTube later. For those, I'm just using 30 FPS, 5000 kbps CBR, and max b-frames at 4 (otherwise the settings are the same). I also wasn't doing anything else on my computer at the time of this latest test recording and the only other things connected over USB are a mouse and keyboard and a Logitech BRIO (all going through a USB hub; the interface is connected directly to a USB-C port).

My initial thought was that there was something wrong with the interface, so I plugged in a THX Onyx I have instead and did a test recording in OBS and sure enough, no problems. So instead of using OBS, I went to Reaper and set about testing the interface there since I can pick and choose which audio driver I want to use to narrow things down. I've tried ASIO, DirectSound, WaveOut, and WASAPI and when I record in Reaper instead of OBS, I have no issues at all. I even lowered the WASAPI buffer size down to its lowest possible setting (144 on my PC, apparently) and still had no issues. Given that that's what OBS is using, I'd expect to see issues there if it was an interface issue, but there weren't any, so I'm at a loss. For all of these test recordings, I just put on an album in Spotify and recorded for a little over 30 minutes, then listened back to the recording (yes, all of it). I did that for every audio driver, so I've now got about 3 hours or so of recordings for troubleshooting this. As you might imagine, I'm getting a little sick of trying to troubleshoot this.

Following Audient's troubleshooting guide, I've also run the LatencyMon utility and the only things that hit above 1 ms are dxgkrnl.sys (this seems to happen when I open my browser), nvlddmkm.sys, Wdf01000.sys, and ndis.sys (if I'm messing about online while recording). But even when those spike, there are no issues in the Reaper recordings.

These stutters happen only in the recorded audio. If I'm just sitting there listening to the music while OBS is recording it, there are no stutters. It is only in the recorded file that there are stutters. The stutters are also present on my mic input, so it seems to just be all audio that has anything to do with this interface, but only when using OBS. All of this leads me to believe that there is something about my OBS settings or about OBS itself that is just not happy with my interface and I don't really know what to do about it. I think the only interface-related thing I have tested is setting OBS to only use one audio stream (ie just recording outputs 1/2, no mics or loopbacks or anything else even active), but I can't think of any good reason why that should matter. Anyone have any ideas?

 

[Thebigcheese]

Okay, I guess I wasn't through driving myself insane, so I set up a test in OBS where the only thing it was even looking at was the loopback input for the interface. At the same time, I recorded that same loopback input in Reaper. I had hoped to be able to just invert the phase of one and render the output, but the OBS audio is slightly longer even though it's the same sample rate. I'll get back to that in a second. Fortunately, it didn't take long to find a difference manually and sure enough, despite the fact that I used WASAPI in Reaper so they'd be using the same audio driver, there is a stutter in the OBS audio that is not present in the Reaper audio. What's more, I can see that it's not a dropout at all but an actual stutter. That's why the OBS audio is longer; if I cut out that silent portion, they would match up again. Screenshot is attached so you can see what I mean. To me, this really indicates that it's an OBS problem and not a hardware or driver problem, but I'm not sure what's causing it or how to fix it. Any ideas?

 

[PaiSand]

Have you tried with CoreAudio AAC encoder?

OBS-Studio: Enable CoreAudio AAC encoder (Windows)

First of all, if you have iTunes or QuickTime installed, chances are you are already using the CoreAudio AAC encoder in OBS-Studio. But if you normally do not use or install any of those, there is another way to enable it. All we need is the...

obsproject.com

 

[Thebigcheese]

Have you tried with CoreAudio AAC encoder?

OBS-Studio: Enable CoreAudio AAC encoder (Windows)

First of all, if you have iTunes or QuickTime installed, chances are you are already using the CoreAudio AAC encoder in OBS-Studio. But if you normally do not use or install any of those, there is another way to enable it. All we need is the...

obsproject.com

I hadn't before, but I have now and it has not made any difference. Still getting the exact same stutters.

 

[Thebigcheese]

Actually, just tried with a custom setup so the audio would output as flac and the stutters are still there, so I don't think it has anything to do with the audio codec.

 

[Thebigcheese]

I really wish I could just edit my existing posts instead of adding new replies, but since I can't... I did some more testing and found that switching to x264 instead of NVENC also made no difference and also that it isn't just limited to the EVO 8, it was also happening when I had the Revelator io44. Both of these devices have ASIO drivers in addition to their normal Windows drivers, whereas the THX Onyx that I tested with and that had no issues does not have ASIO drivers. So the only thing I can think of at this point is that OBS doesn't like devices that have ASIO drivers even though it doesn't use those (I don't have the ASIO plugin installed). I feel like this was not always the case, but I don't know when that might have changed. It has definitely been happening with at least the latest two versions of OBS.

 

[Thebigcheese]

Resurrecting this only because it's still happening 2 years later even with a different Audient interface, a different GPU (now using an AMD 7900 GRE), and on both AMD and Intel encoders. I cannot for the life of me figure out what is causing this, but it's driving me crazy. I've attached my latest log where this happened and it doesn't seem to be a dropped frames thing, either, as I only dropped 4 frames over the course of over two hours. Would really love some guidance on this one.

 

[PaiSand]

I see no issues other than the ones shown on the analyzer

Analyzer | OBS

OBS (Open Broadcaster Software) is free and open source software for video recording and live streaming. Stream to Twitch, YouTube and many other providers or record your own videos with high quality H264 / AAC encoding.

obsproject.com

Display capture must be on its own separated scene, never within game or window capture methods.

You should use the AMD GPU for recording and streaming.
Use 60fps
B-frames should be 2 or 0, not 3.
Base resolution is the resolution of your display monitor. Output resolution is the one you want to output. Most streaming services allow a max of 1080p

You're audio filters are wrong:

19:19:51.761: [Loaded global audio device]: 'Mic (FX)'
19:19:51.761: - filter: 'Downmix makeup' (gain_filter)
19:19:51.761: - filter: 'Gate' (vst_filter)
19:19:51.761: - filter: 'EQ' (vst_filter)
19:19:51.761: - filter: 'Pre-comp' (vst_filter)
19:19:51.761: - filter: 'Comp' (vst_filter)
19:19:51.761: - filter: 'Limiter' (vst_filter)

Gate should always go first unless you apply a noise reduction. Then you can use gain. No need to use compressor and limiter.
This filters are CPU heavy so you don't want to add too much of this and on top use the CPU for streaming.

If you want, create a new profile and use the Auto-configuration Wizard, apply the settings it gives, restart OBS, and now test it as is without changing anything.
One last thing, based on latest experiences the new minimum RAM needed is 32GB, especially on Win 11 and latest games.

 

[Thebigcheese]

I can't use the AMD GPU for both, I have vastly different settings. The Intel encoder performs much better at low bitrates, so that's why I use it there. B frames were set this way based on the recommendations of EposVox. And my audio settings are not in any way "wrong," I have done this all very much on purpose. I'm not trying to be that guy or anything, but I've recorded and mixed albums, and my degree is in both video and audio production, I know what I'm doing here. My gate is set based on the actual levels coming off the preamp, which I set using a DAW because OBS's meters are completely useless, but OBS does not correctly read levels when downmixing a "stereo" input to mono. I say stereo because most interfaces, like the one I'm using, have Windows drivers that treat inputs as stereo pairs rather than individual mono inputs. It reduces the gain by 6 dB as a form of pan law compensation, incorrectly given the context in this case, so the downmix filter brings it back up to the correct level before hitting any processing. After the levels are corrected, THEN it hits the gate. And your statements about compressors and limiters... what? For proper standardized levels, audio should never exceed -1 dB LUFS, that is the entire purpose of the limiter. These are some of the least CPU-intensive plugins on the market (they're all from Fab Filter), so I assure you that's not it, either. It also happens with zero plugins and I'm not using the CPU for streaming anyway, I'm using its dedicated QSV encoder, so the encoder is not affected by any CPU utilization of the plugins.

I do not have game capture and desktop capture enabled at the same time, does it still cause issues? I think I did it this way just to save on buttons on my Stream Deck, but I'll move it to another scene. I rarely use it, it's just nice to have if I want to show the stream something on my desktop.

Why would I use 60 FPS and why does the analyzer call 59.94 a "non-standard" frame rate? I chose it specifically because it IS a standard frame rate and therefore plays nicer with video editing software that is expecting long-established standards. When I had it set to 60, at least with mkv containers I ran into a lot of problems trying to edit. 60 fps is not a standard video frame rate. I find this recommendation truly bizarre, there's an entire NTSC (or I guess it's ATSC now?) standard for this.

I have not changed my base resolution to 1440p because I set up everything before upgrading my monitor and I don't intend on recording or streaming anything at 1440p anyway. Since I record at 1080p, I left that as my base, with streams downscaled to 720p because my internet is not good enough to stream at 1080p at an acceptable quality level. I understand how these things are meant to work, but sometimes you just have to do it a little differently based on reality.

Is there any indication as to why the audio buffering always seems to max out? I can't seem to find any good reason for this. As I've said, the plugins I'm using are extremely light on the CPU and Audient's drivers are generally very well coded. I can run far, far more plugins than this in a DAW with no issues.

I'm going to try disabling HAGS to see if that helps. There are otherwise almost no common factors between my computer now and the computer (actually a laptop, so not even the same installation of Windows) I was using over 2 years ago when I first reported this. Different CPUs, different GPUs, different encoders (happens on x264, Intel, AMD, and Nvidia, then), different plug-ins (and far fewer of them back then), completely different scenes, etc etc. So HAGS (well, and OBS itself) seems to be the only common factor to all of these setups.

 

[PaiSand]

ok, and those recommendations of EpoxVox where made for which OBS version specifically?
We strongly recommend not to follow any youtube guide and only use the Auto-configuration Wizard. Then you can change recording settings as needed on the simple output mode. If you do understand what you're doing then you can go and use the advanced output mode.
Just test it and see if it helps with the recommendations.

For the resolution problem, create a new scene collection using the display resolution. Test it.

 

[Thebigcheese]

ok, and those recommendations of EpoxVox where made for which OBS version specifically?
We strongly recommend not to follow any youtube guide and only use the Auto-configuration Wizard. Then you can change recording settings as needed on the simple output mode. If you do understand what you're doing then you can go and use the advanced output mode.
Just test it and see if it helps with the recommendations.

For the resolution problem, create a new scene collection using the display resolution. Test it.

Unclear, but the video is from about a year ago. I should be clear that this issue is happening on both the latest OBS update and the one before it as well as whatever version I was using two years ago, again with completely different encoders and completely different hardware and completely different OBS settings generally. You can see that log in the OP if you are curious.

 

[rockbottom]

OBS is not causing your pain. Those logs don't look any different than the logs from the beginning of the month. Basically no changes have been made or attempted. Your set-up(s) are bugged with bad settings & other issues. Keep whining & denying or start making changes & troubleshooting.

 

[rockbottom]

The audio gaps in the recording are caused by the audio lagging. After some time, it drifts far enough behind the video & it's corrected on the fly. The gaps are generally only 1ms or less & are barely audible. Need to zoom in on the timeline to find them.

Speed up the audio so the encoder doesn't have to wait for it & the gaps will go away. Most likely you will need to switch to the on-board audio.

 

[Thebigcheese]

They are clearly audible as stutters, unfortunately, often happening in the middle of a word. It is not true that no changes have been made. To clear up your whining in another thread about the errors I was getting, I changed a lot of my browser sources and converted almost entirely to a local bot instead. Most of those errors are gone now. I have swapped audio interfaces. I tried, for that thread, with and without HAGS, to no avail. As you can read in the OP, I've even tried with the same interface using WASAPI drivers, which is what OBS should be using, and had no issues in a DAW recording the same source at the same time as OBS. If it was an issue with the interface or the drivers, it would have popped up there. It is an issue exclusive to OBS. I have spent hours of my life troubleshooting this problem with every conceivable permutation. The denial on this forum is out of control, this issue has persisted for years at this point. I wish anyone here cared about actually fixing problems instead of just pretending they don't exist.

 

[rockbottom]

Again it's not OBS causing your audio to lag. Fix the lag, gaps will cease.

 

[Thebigcheese]

Again it's not OBS causing your audio to lag. Fix the lag, gaps will cease.

The lag only exists in OBS. It is not there in real-time, it is not there in the DAW, it has persisted on two PCs, with and without any and all different sources across two completely separate OBS installs. There's nothing else I can "fix." And a brief search suggests people have been dealing with these OBS-exclusive "max buffering" issues for close to a decade now without a fix, so I'm not the only one.

 

[rockbottom]

Nope, lag is happening before the audio even gets to OBS. It's your rig & settings. If it was OBS, everybody would be in your boat.

 

[Thebigcheese]

People like you really give communities like this a bad name. If you don't have anything actually helpful to say, just don't bother. You haven't even bothered to test the VLC issue because you "know" it isn't an issue and instead waste 10x more of your time telling me so. Why are you even here?

Everyone IS in my boat. There are threads pages long right here about it. You probably even gave a similarly unhelpful response to one of them.

 

[rockbottom]

Again, more BS. Here's some low hanging fruit for ya.

19:19:50.556: Game Bar: On
19:19:50.556: Game DVR: On

19:19:50.786: output 1:
19:19:50.786: name=Q27G3XMN
19:19:50.786: pos={0, 0}
19:19:50.786: size={2560, 1440}
19:19:50.786: attached=true
19:19:50.786: refresh=180 > 120
19:19:50.786: bits_per_color=8
19:19:50.786: space=RGB_FULL_G22_NONE_P709
19:19:50.786: primaries=[r=(0.677734, 0.313477), g=(0.248047, 0.688477), b=(0.149414, 0.057617), wp=(0.313477, 0.329102)]
19:19:50.786: relative_gamut_area=[709=1.374653, P3=1.013354, 2020=0.727014]
19:19:50.786: sdr_white_nits=80
19:19:50.786: nit_range=[min=0.051300, max=1156.000000, max_full_frame=1156.000000]
19:19:50.786: dpi=96 (100%)
19:19:50.786: id=\\?\DISPLAY#AOCB326#7&d7f124a&0&UID1032#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}
19:19:50.786: alt_id=\\.\DISPLAY1
19:19:50.786: output 1:
19:19:50.786: name=24G2W1G4
19:19:50.786: pos={2560, 200}
19:19:50.786: size={1920, 1080}
19:19:50.786: attached=true
19:19:50.786: refresh=144 > 120
19:19:50.786: bits_per_color=8
19:19:50.786: space=RGB_FULL_G22_NONE_P709
19:19:50.786: primaries=[r=(0.664062, 0.308594), g=(0.275391, 0.669922), b=(0.154297, 0.050781), wp=(0.313477, 0.329102)]
19:19:50.786: relative_gamut_area=[709=1.269063, P3=0.935517, 2020=0.671171]
19:19:50.786: sdr_white_nits=80
19:19:50.786: nit_range=[min=0.500000, max=270.000000, max_full_frame=270.000000]
19:19:50.786: dpi=96 (100%)
19:19:50.786: id=\\?\DISPLAY#AOC2402#7&d7f124a&0&UID1024#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}
19:19:50.786: alt_id=\\.\DISPLAY2

19:19:50.786: Adapter 1: Intel(R) UHD Graphics 730
19:19:50.786: Dedicated VRAM: 134217728 (0.1 GiB)
19:19:50.786: Shared VRAM: 8469237760 (7.9 GiB)
19:19:50.786: PCI ID: 8086:4692
19:19:50.786: HAGS Status: Disabled (Default: No, Driver status: Experimental)
19:19:50.787: Driver Version: 31.0.101.4577 > Stale/Update

19:19:50.821: Hardware-Accelerated GPU Scheduling enabled on adapter!

(Audient iD14)(Audient iD14)(Audient iD14)(Audient iD14)(Audient iD14)(Audient iD14)

19:19:52.405: - scene 'PC games':
19:19:52.405: - source: 'Left monitor' (monitor_capture)
19:19:52.405: - source: 'Game' (game_capture)

19:19:54.878: [obs-browser: 'Chat'] Error: Access to XMLHttpRequest at 'https://api.chatterino.com/badges' from origin 'https://www.giambaj.it' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. (https://www.giambaj.it/twitch/jchat...font=1&stroke=1&shadow=2&hide_commands=true:0)

 

[rockbottom]

A flawed decade of OBS. Sooner or later you'll figure it out. Maybe it's today, maybe not.