Question / Help Audio in recordings gets ruined when "Max audio buffering reached!"

6

62a

New Member
I'm making gameplay recordings, and OBSS does not always correctly record the audio. Sometimes the audio throughout an entire video will be skipping. Sometimes it will suddenly speed up (sometimes moderately, sometimes drastically) in the middle of the video and then end before the video's over. Sometimes videos just have no sound at all. Whenever these problems occur, I look at the log file and somewhere I find the line "Max audio buffering reached!" Sometimes when there are no problems I look at the log file, and then I never see that line. I have buffering disabled for all the sources I use, and I can't find any other buffer-related settings to adjust.

Now there are some hardware-related factors which I suspect may have something to do with this. A few weeks ago, my stupid Dell laptop started having sporadic problems related to the power adapter and battery. It wouldn't recognize the power adapter type and the battery wouldn't charge. And when this started was when the audio recording problems started. Initially the correlation was pretty clear. Whenever my laptop gave that power adapter warning on boot and/or the battery wouldn't charge, recorded audio would get mangled. Otherwise recordings would turn out fine. The people at a laptop repair place (which is also the place I bought the laptop from) said the CPU gets drastically underclocked if the machine thinks the power adapter is under-wattage, which could cause some programs to malfunction.

Another thing I noticed that coincided exactly with these power adapter problems: When I'd click "Stop Recording" in OBSS, it would take a really long time for the recording to stop. The button would say "Stopping Recording..." for about a minute or more. Sometimes it would just stay there, with the recording clock ticking up, until I closed OBSS. Whenever this happened, it was a pretty reliable indicator that the audio was ruined. If the recording stopped quickly and smoothly, it meant the audio was fine.

So you'd think that if I fixed this problem with my laptop then my recordings would be fine again, right? Unfortunately not. The repair place gave me a new power adapter (fortunately covered by hardware warranty) and it seemed to totally fix the adapter/battery problems. And now OBSS just takes a second or so to stop recording (which, however, is not quite as speedy as it usually was before any of these problems). But my recordings are still sometimes being ruined by this max audio buffering nonsense!

I really, really want to fix this! Even if it means editing the source code of OBSS and compiling it myself.

This log is from my most recent failed recording attempt, so after the resolution of the power adapter issue. I made a couple of test recordings and they were fine. But then (of course) when I tried to make a real gameplay recording there was no sound. I made another test recording after that and it also had no sound. And the log shows that "Max audio buffering reached!" happened after the recordings with sound and before the ones without.
Code: 
10:44:23.977: CPU Name: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
10:44:23.978: CPU Speed: 2494MHz
10:44:23.978: Physical Cores: 2, Logical Cores: 4
10:44:23.978: Physical Memory: 8072MB Total, 5862MB Free
10:44:23.978: Windows Version: 10.0 Build 15063 (revision: 296; 64-bit)
10:44:23.978: Running as administrator: false
10:44:23.978: Aero is Enabled (Aero is always on for windows 8 and above)
10:44:23.978: Portable mode: false
10:44:24.022: OBS 19.0.3 (64bit, windows)
10:44:24.022: ---------------------------------
10:44:24.023: ---------------------------------
10:44:24.023: audio settings reset:
10:44:24.023:     samples per sec: 48000
10:44:24.023:     speakers:        2
10:44:24.024: ---------------------------------
10:44:24.024: Initializing D3D11...
10:44:24.025: Available Video Adapters:
10:44:24.026:     Adapter 1: Intel(R) HD Graphics 3000
10:44:24.026:      Dedicated VRAM: 33554432
10:44:24.026:      Shared VRAM:    1711276032
10:44:24.027:      output 1: pos={0, 0}, size={1366, 768}, attached=true
10:44:24.031: Loading up D3D11 on adapter Intel(R) HD Graphics 3000 (0)
10:44:24.033: D3D11 loaded successfully, feature level used: 41216
10:44:25.200: ---------------------------------
10:44:25.200: video settings reset:
10:44:25.200:     base resolution:   256x224
10:44:25.200:     output resolution: 256x224
10:44:25.200:     downscale filter:  Lanczos
10:44:25.200:     fps:               262144/4389
10:44:25.200:     format:            NV12
10:44:25.201: Audio monitoring device:
10:44:25.201:     name: Default
10:44:25.201:     id: default
10:44:25.201: ---------------------------------
10:44:25.219: [CoreAudio encoder]: CoreAudio AAC encoder not installed on the system or couldn't be loaded
10:44:25.247: [AMF] Encountered Exception during AMF initialization: Unable to load 'amfrt64.dll', error code 126.
10:44:25.247: Failed to initialize module 'enc-amf.dll'
10:44:25.337: LoadLibrary failed for 'nvEncodeAPI64.dll': The specified module could not be found.
10:44:25.337:  (126)
10:44:25.641: Couldn't find VLC installation, VLC video source disabled
10:44:25.717: No blackmagic support
10:44:25.807: ---------------------------------
10:44:25.807:   Loaded Modules:
10:44:25.807:     win-wasapi.dll
10:44:25.807:     win-mf.dll
10:44:25.807:     win-dshow.dll
10:44:25.807:     win-decklink.dll
10:44:25.807:     win-capture.dll
10:44:25.807:     vlc-video.dll
10:44:25.807:     text-freetype2.dll
10:44:25.807:     rtmp-services.dll
10:44:25.807:     obs-x264.dll
10:44:25.807:     obs-vst.dll
10:44:25.807:     obs-transitions.dll
10:44:25.807:     obs-text.dll
10:44:25.807:     obs-qsv11.dll
10:44:25.807:     obs-outputs.dll
10:44:25.807:     obs-filters.dll
10:44:25.807:     obs-ffmpeg.dll
10:44:25.807:     image-source.dll
10:44:25.807:     frontend-tools.dll
10:44:25.807:     enc-amf.dll
10:44:25.807:     coreaudio-encoder.dll
10:44:25.807: ==== Startup complete ===============================================
10:44:25.809: Service '' not found
10:44:25.847: All scene data cleared
10:44:25.847: ------------------------------------------------
10:44:25.924: Switched to scene 'Single'
10:44:25.924: ------------------------------------------------
10:44:25.924: Loaded scenes:
10:44:25.924: - scene 'Single':
10:44:25.924:     - source: 'SGB2' (dshow_input)
10:44:25.924: - scene 'Double':
10:44:25.924:     - source: 'SGB2' (dshow_input)
10:44:25.924:     - source: 'GB' (dshow_input)
10:44:25.924: ------------------------------------------------
10:44:26.165: ---------------------------------
10:44:26.165: [DShow Device: 'SGB2'] settings updated:
10:44:26.165:     video device: GV-USB2, Analog Capture
10:44:26.165:     video path: \\?\usb#vid_04bb&pid_0532#000000000000001#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\{6f814be9-9af6-43cf-9249-c0345a000211}
10:44:26.165:     resolution: 352x240
10:44:26.165:     fps: 59.94 (interval: 166833)
10:44:26.165:     format: YUY2
10:44:26.166:     using video device audio: yes
10:44:26.167:     sample rate: 48000
10:44:26.167:     channels: 2
10:44:26.167:     audio type: Capture
10:44:26.314: adding 21 milliseconds of audio buffering, total audio buffering is now 21 milliseconds
10:44:47.012: rtmp-common.c: [initialize_output] Could not find service ''
10:44:47.013: ---------------------------------
10:44:47.013: [x264 encoder: 'recording_h264'] preset: superfast
10:44:47.013: [x264 encoder: 'recording_h264'] profile: high
10:44:47.013: [x264 encoder: 'recording_h264'] settings:
10:44:47.013:     rate_control: CRF
10:44:47.013:     bitrate:      0
10:44:47.013:     buffer size:  0
10:44:47.013:     crf:          15
10:44:47.013:     fps_num:      262144
10:44:47.013:     fps_den:      4389
10:44:47.013:     width:        256
10:44:47.013:     height:       224
10:44:47.013:     keyint:       250
10:44:47.013:     vfr:          on
10:44:47.013:
10:44:47.019: ---------------------------------
10:44:47.020: [FFmpeg aac encoder: 'SGB2'] bitrate: 320, channels: 2
10:44:47.027: ==== Recording Start ===============================================
10:44:47.027: [ffmpeg muxer: 'adv_file_output'] Writing file 'C:/Users/Owner/L/G/rec/all/ftg/P/RB/L0/S1/G1/1707101044.mkv'...
10:48:22.218: [ffmpeg muxer: 'adv_file_output'] Output of file 'C:/Users/Owner/L/G/rec/all/ftg/P/RB/L0/S1/G1/1707101044.mkv' stopped
10:48:22.218: Output 'adv_file_output': stopping
10:48:22.218: Output 'adv_file_output': Total encoded frames: 12851
10:48:22.218: Output 'adv_file_output': Total drawn frames: 12853
10:48:22.219: ==== Recording Stop ================================================
10:48:22.228: warning: 2 frames left in the queue on closing
10:52:53.935: rtmp-common.c: [initialize_output] Could not find service ''
10:52:53.935: ---------------------------------
10:52:53.935: [x264 encoder: 'recording_h264'] preset: superfast
10:52:53.935: [x264 encoder: 'recording_h264'] profile: high
10:52:53.935: [x264 encoder: 'recording_h264'] settings:
10:52:53.935:     rate_control: CRF
10:52:53.935:     bitrate:      0
10:52:53.935:     buffer size:  0
10:52:53.935:     crf:          15
10:52:53.935:     fps_num:      262144
10:52:53.935:     fps_den:      4389
10:52:53.935:     width:        256
10:52:53.935:     height:       224
10:52:53.935:     keyint:       250
10:52:53.935:     vfr:          on
10:52:53.935:
10:52:53.941: ---------------------------------
10:52:53.941: [FFmpeg aac encoder: 'SGB2'] bitrate: 320, channels: 2
10:52:53.949: ==== Recording Start ===============================================
10:52:53.949: [ffmpeg muxer: 'adv_file_output'] Writing file 'C:/Users/Owner/L/G/rec/all/ftg/P/RB/L0/S1/G1/1707101052.mkv'...
11:04:07.351: [ffmpeg muxer: 'adv_file_output'] Output of file 'C:/Users/Owner/L/G/rec/all/ftg/P/RB/L0/S1/G1/1707101052.mkv' stopped
11:04:07.351: Output 'adv_file_output': stopping
11:04:07.351: Output 'adv_file_output': Total encoded frames: 40219
11:04:07.351: Output 'adv_file_output': Total drawn frames: 40220
11:04:07.352: ==== Recording Stop ================================================
11:04:07.357: warning: 2 frames left in the queue on closing
11:04:08.916: Max audio buffering reached!
11:04:08.916: adding 938 milliseconds of audio buffering, total audio buffering is now 960 milliseconds
11:08:26.058: rtmp-common.c: [initialize_output] Could not find service ''
11:08:26.059: ---------------------------------
11:08:26.059: [x264 encoder: 'recording_h264'] preset: superfast
11:08:26.059: [x264 encoder: 'recording_h264'] profile: high
11:08:26.059: [x264 encoder: 'recording_h264'] settings:
11:08:26.059:     rate_control: CRF
11:08:26.059:     bitrate:      0
11:08:26.059:     buffer size:  0
11:08:26.059:     crf:          15
11:08:26.059:     fps_num:      262144
11:08:26.059:     fps_den:      4389
11:08:26.059:     width:        256
11:08:26.059:     height:       224
11:08:26.059:     keyint:       250
11:08:26.059:     vfr:          on
11:08:26.059:
11:08:26.065: ---------------------------------
11:08:26.065: [FFmpeg aac encoder: 'SGB2'] bitrate: 320, channels: 2
11:08:26.073: ==== Recording Start ===============================================
11:08:26.073: [ffmpeg muxer: 'adv_file_output'] Writing file 'C:/Users/Owner/L/G/rec/all/ftg/P/RB/L0/S1/G1/1707101108.mkv'...
11:27:30.193: [ffmpeg muxer: 'adv_file_output'] Output of file 'C:/Users/Owner/L/G/rec/all/ftg/P/RB/L0/S1/G1/1707101108.mkv' stopped
11:27:30.193: Output 'adv_file_output': stopping
11:27:30.194: Output 'adv_file_output': Total encoded frames: 68334
11:27:30.194: Output 'adv_file_output': Total drawn frames: 68336
11:27:30.194: ==== Recording Stop ================================================
11:27:30.205: warning: 2 frames left in the queue on closing
11:38:27.398: rtmp-common.c: [initialize_output] Could not find service ''
11:38:27.399: ---------------------------------
11:38:27.399: [x264 encoder: 'recording_h264'] preset: superfast
11:38:27.399: [x264 encoder: 'recording_h264'] profile: high
11:38:27.399: [x264 encoder: 'recording_h264'] settings:
11:38:27.399:     rate_control: CRF
11:38:27.399:     bitrate:      0
11:38:27.399:     buffer size:  0
11:38:27.399:     crf:          15
11:38:27.399:     fps_num:      262144
11:38:27.399:     fps_den:      4389
11:38:27.399:     width:        256
11:38:27.399:     height:       224
11:38:27.399:     keyint:       250
11:38:27.399:     vfr:          on
11:38:27.399:
11:38:27.404: ---------------------------------
11:38:27.405: [FFmpeg aac encoder: 'SGB2'] bitrate: 320, channels: 2
11:38:27.412: ==== Recording Start ===============================================
11:38:27.412: [ffmpeg muxer: 'adv_file_output'] Writing file 'C:/Users/Owner/L/G/rec/all/ftg/P/RB/L0/S1/G1/1707101138.mkv'...
11:39:10.322: [ffmpeg muxer: 'adv_file_output'] Output of file 'C:/Users/Owner/L/G/rec/all/ftg/P/RB/L0/S1/G1/1707101138.mkv' stopped
11:39:10.322: Output 'adv_file_output': stopping
11:39:10.322: Output 'adv_file_output': Total encoded frames: 2561
11:39:10.322: Output 'adv_file_output': Total drawn frames: 2563
11:39:10.323: ==== Recording Stop ================================================
11:39:10.329: warning: 2 frames left in the queue on closing
 
6

62a

New Member
Update: Now if you click on that link in my last post, you'll see that the main thread about this issue has been closed to further replies.

That wasn't the case yesterday. In fact I posted in it yesterday, commenting on how multiple people have posted in it, during different months over the past year, saying they have this problem, and yet nobody has attempted to offer a real solution or even brainstorm about what the cause could be. I pointed out that it looks like the people who could help solve this particular problem are deliberately ignoring it for some reason. Like maybe it's a bug that the devs have decided they're just not going to fix because it doesn't affect anybody they care about. Of course that's probably not actually the case, but it looks bad nonetheless.

And guess what? Some moderator actually read my post, and their response was to delete it and lock the thread.

Think about that for a minute. The thread makes it clear that there is a very real problem with OBSS that has been affecting multiple users for at least a little over a year now. It also makes it clear that there has been zero public attention to the problem by devs and other knowledgeable people. And somebody with some authority in the community came along and read that thread.

Put yourself in that moderator's shoes. What would you do? Most reasonable people would probably post an acknowledgement of the problem, and either some helpful information or a statement of intent to bring the issue to the attention of someone who knows enough to help. But what did this particular moderator decide to do? Silence the person pointing out the fact that the issue is being ignored (which comically plays into the conspiracy theory that the ignoring is deliberate), and lock the thread to prevent similar observations from being posted there in the future, as well as prevent any further discussion regarding the still-unresolved and totally unexplored issue from occurring there.

I wonder if that moderator's actions reflect the values of this community as a whole. Is this a place where making software work correctly is less important than silencing all criticism of the people who know how to make it work? Or was that particular moderator just an authoritarian personality led astray by their primal urges?
 
Harold

Harold

Active Member
Now if you click on that link in my last post, you'll see that the main thread about this issue has been closed to further replies.
Click to expand...
Because there is no actual "main thread" for this issue.
 
Harold

Harold

Active Member
If there were a main thread for the issue it would have more troubleshooting in it that one guy that posted logs and a bunch of "me too" posters that added nothing.
 
6

62a

New Member
Whether or not it meets your particular special definition of a "main thread" is irrelevant. You seem to be assuming that if you can establish that there is no "main thread" proper, then that justifies the silent locking of the thread with no open acknowledgement of the fact that the issue is still unresolved. But obviously that's just silly. The conclusion does not follow from the premise.

What's really important here is not precisely what a main thread is, but rather what it does, and that is to serve as a common point of contact for all people who have an interest in a particular topic.

Now that that thread is locked, people who have posted in it no longer have hope of receiving notifications of helpful new replies. People who have the problem no longer have a single common place to potentially get together and discuss it, and that will probably make it harder to solve the problem. If the thread weren't locked then maybe it could improve and become useful, but now there's no chance of that, thanks to the mysterious, totally anonymous moderator who locked it.

Say, I just noticed something! You're a "Community Helper". Boy, am I ever glad you've showed up here! Because, y'know, I need help with OBS and all.

Now I realize you're doing a highly valuable service to the community by using irrelevant arguments about the meaning of the term "main thread" to defend the decisions of the mysterious, anonymous moderator who locked that thread. You're being very helpful and there's no doubt about that.

But do you think, just maybe, you could take a little break from that, to help me resolve this issue I'm having with the software, or at least make some substantive comment about it? After all, getting help with OBS is the reason why I posted here in the first place and the entire purported purpose of this forum. Or is that just not important enough compared to defending the honor of that mysterious, totally anonymous moderator?

I'm not overloading my system BTW. Just a random thing I thought I'd mention. :)
 
6

62a

New Member
That seems unlikely. The capture device is the only thing plugged into any of my USB ports, and it's only transmitting a single video stream with a puny 352x240 resolution, plus one stereo audio stream. Is there a set amount of data flow they can handle or does it vary? Because it's definitely possible that my laptop hardware is junk. It is a Dell.

Incidentally, I went and looked at the source file obs-audio.c, and while I certainly haven't had time to figure out exactly how it all works, I did notice some interesting things.

It basically looks like the size of the audio buffer gets increased whenever OBS thinks a source has "gone backward in time", which I guess means the timestamps are in the wrong order or something like that. When the buffer is increased it increases a "buffering ticks" variable, and when these ticks reach a set maximum number (45) is when the telltale error message is printed. Interestingly though, I don't see any code that appears to be capable of decreasing the buffer. So what happens is that every timestamp discrepancy just increases the size of the buffer, and when the buffering ticks reach 45, the audio buffer is considered too big and all further audio input is in vain.

I wonder if it's really necessary for the buffer to keep getting bigger and never shrink. In any case, it looks like one quick workaround might be to increase the max buffering ticks from 45 to something much higher. Then the audio buffer is allowed to get really big, but how bad could that be? I don't see it eating all my RAM. Perhaps I should post in the bug report forum, since I find it hard to imagine that the developers intended for audio functionality to shut down as a result of a few wrongly ordered timestamps.
 
6

62a

New Member
UPDATE: I found a workaround.

Short version: I kept buffering off in the device properties, and I changed the sync offset to 30 ms where it had previously been zero. Now I never ever see anything about audio buffering in logs. It's like having woken up from a nightmare. Actually, it's like having finally REALLY woken up from a nightmare within a nightmare within a nightmare etc. But I guess you all don't know about that. Anyway.

I call this a workaround rather than a solution, because it seems to do nothing to resolve the underlying problem, whatever that may be. It used to be that my recordings always turned out fine even without the settings like this. When I get a new laptop, it will be interesting to see if that is the case again.

I'm not sure this workaround will necessarily work for everyone else who has this problem. The device I'm mostly using is a GV-USB2. The exact symptoms seem to vary depending on what device is being used, and they actually seem to have possibly changed since I started this thread. Different symptoms suggest different cures. I didn't do any testing beyond what was necessary to enable decent recordings again though.

Sync offset seems to guard against audio buffering increases. Basically, if you see a log line saying some amount of time was added to the audio buffer, then you should make the sync offset greater than the amount that was added. I was seeing lots of lines saying "adding 21 milliseconds of audio buffering...", so I changed the sync offset to 30 ms and it prevented all those.

BUT that alone isn't not good enough, as I discovered when I tried enabling buffering in the device properties. For some reason, this caused occasional big increases in audio buffering. So instead of using a huge sync offset I just kept buffering off.

Now what's funny is, if you look at that log file I posted initially, there's a part where the audio buffering increases by 938 ms, even though I had buffering off. So I don't know what to make of that. I don't think I could reproduce something similar now. It's why I said the symptoms seem to have changed. I can't wait to get my new laptop.

But what about my talk of modifying the source? Well I tried that and it didn't work. I set MAX_BUFFERING_TICKS to a really high number, and indeed that prevented the part where it says "Max audio buffering reached!" and the audio stops. But this only forced me to see the problem on a slightly deeper level: Every increase in audio buffering corresponds to a hiccup in the audio, and with every hiccup the audio and video become more desynchronized. So you can let the audio buffer get really big, but then the audio in your recording will be off a huge amount of time, and it will have lots of irritating hiccups.

Out of curiosity I also tried disabling the audio buffer altogether. This just resulted in the audio abruptly stopping when the audio buffer normally would have been made nonzero.
 
Last edited:
C

cnunes73ucb

New Member
Let's go to VMIX, it doesn't happen there.
Here support does not answer this problem that has been around for a long time and nobody solves it!!
Terrible
 
C

cnunes73ucb

New Member
After use this attached configuration I never saw the problem again.
 

Attachments

  • Configuração Catedral_19052020.pdf
    683.7 KB · Views: 449
You must log in or register to reply here.
Top