Question / Help Audio drift

Hansaplast26

New Member
A couple of days ago I posted an issue I have with regards to audio drift in the Mac support group.
My camera is a foscam IP camera, in OBS used via RTSP, with a clap test I adjusted the audio delay, around 2200 ms. however it keeps drifting and i never seem to get the audio right.


I now moved to Windows so I can use nvenc. Set up OBS on Windows 10. all works well, but my issue with audio drifting away is still there:-(
I had hoped that the option 'Use device timestamps' would sort out the problem. I also toggled between 48khz and 44.1khz as the logfile stated that my audio devices work at 44.1khz

attached is the logfile. hope somebody has a good clue.
 

Attachments

If there is too much latency in the system, be it hardware or software, when taking in a constant stream of data it will inevitably build up as the chain or system cannot do it fast enough. It doesn't mean there isn't enough cpu power, that memory isn't fast enough, but rather, as a whole it just isn't good enough. I ran into this situation years ago with some early days usb capture device, and the solution was to attach the device directly unto the motherboard itself. Bypassing the latency from usb port and from across there to the other side of the motherboard, to reach the chipset.
However it is also greatly a matter of protocol and it's efficiency.

Going over a network protocol you have some tools at your disposal.
I would disable interrupt/moderation, set buffers to minimum - typically 80 lowest. Other settings shouldn't really affect it too much, tho i disable LSO and such. The list of tweaks that can be done is quite lengthy and would go on for many pages.

Back in the day some also reported of latency improvements in moving the whole tcp stack to be in RAM itself, a tweak that's actually technically still possible - but really shouldnt be necessary anymore. A good graphical software tool for this would be TCP Optimizer. last version 4.10 or so. You'll need to run it as admin. It's a bit buggy but it gives you an oversight of things to adjust.

Overrall, system drivers, good managment, a clean system without bloatware etc, can have just as much impact for keeping system latency to a stable value. Not to mention a well configured bios with detailed settings.

14:15:10.494: Running as administrator: false
14:15:10.499: Game DVR: On
14:15:12.108: WASAPI: Device 'Microphone (HD Pro Webcam C920)' [16000 Hz] initialized
Consider disabling webcam mic/audio if you dont need it, so it doesnt ping the audio stack

turn this off for now
14:15:48.250: psycho_aq: true

your biggest concern here is :
14:25:32.895: Number of memory leaks: 2

14:15:11.752: base resolution: 1920x1080
14:15:11.752: output resolution: 1920x1080
14:15:11.752: downscale filter: Bicubic
14:15:11.752: fps: 25/1

1920x1080p at 25fps isn't actually a very healthy streaming resolution. You really should be only, ever, be doing either 30 or 60. and even at 4500 bitrate you're cutting it quite hard. 1280x720p is much more healthier with 6000 bitrate.
 
Thank you for your answer! The machine is quite old (but relatively powerful with a 2.53 Ghz Xeon quad core). It is a Dell precision T5500 with upgraded power supply, Nvidia GTX 1650 and SSD harddrive. The Windows 10 install is fresh and while running OBS streaming and recording the CPU load is hovering around 10 to 15%.

The machine is dedicated for streaming so nothing else is or gets installed than OBS, VLC and Filmora (to determine the audio sync delay).

I download TCP Optizimer and looking at some settings. The IP Camera is streaming at 4Mbit, 1920x1080 at 25 frames /sec. This is the max it can do.

So a number of remarks / questions

- We're talking TCP, I am receiving 4 Mbit of video, streaming at 4.5 Mbit, That is roughly 10 Mbit, even a Raspberry Pi is handling this amount of data with two fingers in its nose. Moreover TCP doesn't 'loose' packets, and the bitrate isn't too fancy either. And for the Media source there is a buffer of 2 MB. this should give a nice steady amount of data. I understand you are basing this on experience, but I would expect the NIC the last to cause latency problems.

- In OBS if I go to view > stats I see that I have 0 frames lost, no rendering lag, no encoding lag. average time to render is 1.3ms about. If I stream at 25 FPS I have 40 ms (!) to get a single frame ready. If I'd change to 30FPS I would still have plenty of time, 33.3ms - 1.3ms = 32ms...

- The memory leaks are concerning. I see from the logs that I either have 0 or 2. how can I determine where they come from?

- Why would I change FPS to 30, that would be asking for trouble if my input source is 25 FPS?

- The logitech audio at 16khz is not being used by me in my set up.
 
I once saw a small white coffee beetle baby destroy a computer. It just walked into a transistor and the computer instantly turned it self off and died.

It's a very strange world.

In the 30/60 fps thing, very short - it's a good rule of thumb for your outside will expect one or the other. It's such a lengthy boring thing to discuss.
I would probably still set your fps to 30 and not give 2 f's if your camera's max is 25. I understand your concern, and it simply doesnt matter. It's a "I cant even topic". At the very least you should give it a go. Im not saying this is the problem here

Like i said it's not a matter of individual computing prowess of an individual part necessarily. I'm curious how your filmora software itself affects this and how it is without it.

If something is not being used, disable it. You are in a search for a culprit and you need to eliminate what you can.

this also seems quite concerning:
14:15:18.335: warning: 'circular_buffer_size' option was set but it is not supported on this build (pthread support is required)
14:15:18.336: warning: 'circular_buffer_size' option was set but it is not supported on this build (pthread support is required)
That shouldnt be happening, have you overwritten some files or such?

Coffee time.
 
I also had drift issues with OBS on two Mac's. Which got me thinking if this would be the same issue. which would mean that it it could be related to the camera or the decoding of the camera picture. Why would it be in the encoding part if there are no overloading issues (as I found)
I did the following, note I have two IP camera's.
- On both IP camera I switched on a visual timestamp (OSD), with seconds being displayed
- On the windows and the mac computer I connected to the camera as 'media source'.

In the beginning the delay was about 2 to 3 seconds. after a couple of hours it was 6 seconds. <- that is my drift!

On the Windows machine I changed the Media Source type to VLC source type, left it overnight and did not observe a drift.
Seems I found my culprit!

PS, tell me, how is OBS going to make a smooth video if 25 frames need to be stretched to 30 frames in one second?
 
Are you saying that you kept everything the same and only changed the source type to VLC instead of media source?

I had severe issues today with a new setup that seem to relate to what you were dealing with. New Canon XA40 camcorder attached to new ATEM Mini via HDMI. ATEM attached via high speed USB to brand new Windows 10 PC. When recording in OBS or livestreaming to YouTube, the audio from the camera was several seconds later than the video. Restarted OBS, and the sync problem went away immediately.

Later, everything was going along fine until we switched to another scene+audio source in OBS. When we switched back, there was NO audio from the ATEM, even though everything from the sound mixer board to the camera was fine. We had to scramble to get something sort of working with an IP cam and audio source.

Any ideas?

Sorry I don't have a log available at my fingertips. Will be looking at it when I get the next opportune time.
 
Are you saying that you kept everything the same and only changed the source type to VLC instead of media source?

I had severe issues today with a new setup that seem to relate to what you were dealing with. New Canon XA40 camcorder attached to new ATEM Mini via HDMI. ATEM attached via high speed USB to brand new Windows 10 PC. When recording in OBS or livestreaming to YouTube, the audio from the camera was several seconds later than the video. Restarted OBS, and the sync problem went away immediately.

Later, everything was going along fine until we switched to another scene+audio source in OBS. When we switched back, there was NO audio from the ATEM, even though everything from the sound mixer board to the camera was fine. We had to scramble to get something sort of working with an IP cam and audio source.

Any ideas?

Sorry I don't have a log available at my fingertips. Will be looking at it when I get the next opportune time.

Basically yes, the only thing changed for me was from Media Source to VLC.
Prior to that I made sure that the FPS for all devices was the same and also the sampling rate for the audio inputs matched (as much as possible). You can learn a lot from the logs about this.

I also believe that audio drift sync problems cannot come from encoding, unless there is a severe performance problem on the computer.
I have no fancy equipment like the atem mini at my disposal, if you suspect a problem with it, I would try to take it out during testing / tweaking for the sake of eliminating unknowns. if your problem persists, then at least you ruled out what not the cause was.

BTW Highspeed USB is a definition that was introduced with USB 2.0, allowing communication up to 480Mbit/s. Essentially USB 1.1 isn't really around anymore, so Highspeed USB is what everybody has. USB 3.0 allows faster speeds.
 
Back to this...is the idea that VLC processes the IP cam video in a more timely fashion than the built-in code in OBS that handles a media source?
 
I am experiencing this exact same audio drift problem on MacOS on 25.x, no indication in stats that there's anything wrong, CPU is low, and yet audio can end up 1-2 seconds out of sync within a minute of starting recording. This is on an ATEM Mini. I notice that even though I'm supposed to be capturing from the Video Source at 60fps the actual value is something like 59.999999 fps, not sure if that's causing some kind of sync issue or there's some decoding performance issue. No idea.
 
Well usb devices are to some extent affected by power saving features, especially in regard to also what concerns the cpu. There's that, and the other major factor is the usb chipset and how it's implemented on the motherboard.

We can do stuff in regard to power saving features either in BIOS or in operating system, as in disabling everything. There is not much more to be done here, except also making sure everything is running at optimal settings, and RAM timings are as tight as they could be and we are giving just the right amount of voltage to the components and dont have an overshoot or a too high of a drop of voltage.
This is all rather boring to do and can be very time consuming. We can't really move further into that discussion because each use case will have their own hardware.

But remember this, hardware companies are testing their stuff on verified stable systems that have gone thru qualification to be deemed as such. For the most part the casual user just bought a pc and stuffed some components in it, or worse bought a mac, and have the same expecations. And as i wrote that i saw the person writing above has a mac, which is just unfortunate.

If possible see if strengthening cpu clock or as i said disabling power saving features help.
Good tools for stability is RamTest by Karhus, Realbench 2.56 for AVX, 2.44 for non avx, cinebench, aida64, super pi, gsat and many more. Consider testing with and without HT/SMT etc.
 
Helpful info. Thanks for the pointers. Update: today's livestream went better, but still problems with the Canon XA40-HDMI-ATEM Mini-USBC-brand new unmodified Dell PC. (Vostro MT 3671, 32 GB RAM, Core i5-9400, M.2 PCIe NVMe SSD).

The Canon camcorder audio started out sync'd with video perfectly. About 10 minutes into the livestream, there was a hiccup that was visible on Youtube. After that, the audio was late by a second or so. It presents to the public very poorly. We had to switch over to our IP cam backup which is in perfect sync with itself, but a second or so delayed from the Canon. What I don't understand is how the audio and video can be allowed to get out of sync--either by the ATEM mini or the PC. Shouldn't they be "pinned" together so that at least they are sync'd? Slightly more delay to the stream would be far better than out of sync video+audio. That said, I still can't say with certainty what our culprit is. Camera? ATEM Mini? PC? Anyone have an educated guess on that?

About the IP cams, by the way, changing them to be a VLC Source instead of a run-of-the-mill Media Source did the trick. Audio latency was reduced drastically, and drift between the two IP cams seems to have been eliminated. Excellent upgrade for us. Right now, I can't believe it, but $200 IP cams are more reliable than the much more expensive Canon camcorder.
 
.. changing them to be a VLC Source instead of a run-of-the-mill Media Source did the trick.

It's weird to me how so many, speaking in general, are unfamiliar with VLC. it's the goddamn media tool of the last few decades, and people magically just finds it to fix everything as if "oh look at this 'new' thing".

$200 IP cams are more reliable than the much more expensive Canon camcorder.

I like Sony's handcams, as they can be run 24/7, have some decent options for stuff like green screen and other filters, can record simultaneously while playback over hdmi, flip-able screens, nice remote controller as accessory and generally just works great. They don't run hot either, which is a big plus imo. I don't think canon has any good offerings in the lower price bracket that sony, at least used to, have or had. For camcorders.
Sony's can also be run without need to attach to a computer and will happily work off battery, obviously, and the battery time is quite good for regular 1080p. I have infact, nothing negative to say about them. They also attach great to a multitude of cam holders that i've tried, from cheap ebay gear to professional level. And they can be had in the same, or least used to-again, price range as your ip cams.

About 10 minutes into the livestream, there was a hiccup that was visible on Youtube. After that, the audio was late by a second or so. It presents to the public very poorly. We had to switch over to our IP cam backup which is in perfect sync with itself, but a second or so delayed from the Canon. What I don't understand is how the audio and video can be allowed to get out of sync--either by the ATEM mini or the PC. Shouldn't they be "pinned" together so that at least they are sync'd? Slightly more delay to the stream would be far better than out of sync video+audio.

You do have an option to manual set either video or audio offset, in OBS by adding a filter to the source. And for audio u also have advanced audio properties. If the data feed, audio+video, from the canon cam is drawn out over a single cable, usb-c in this case, then the fact that it's audio drifting suggests to me poor implementation by developer. Tho perhaps you need better drivers or such. Firmware update?
Many report that after adding a filter with offset that fixes it for various products, but in reality this shouldnt have been an issue - i think we can agree on that. Haven't done any audio testing on Atem mini yet, which is unfortunate, but i have other priorities. There have been a few threads rising tho with BMD related issues lately. I think the better idea here is to just find a solution that works for now, while drivers can be allowed to mature for such devices.

I strongly recommend system testing anyway, to make sure you have a good base system thats stable, because it will simply tell you if there are factors you havent considered and which may be having problems that you're not aware of. Have no reason to think thats the case, doesnt hurt to test anyway.
 
The audio or video offset controls are clearly not an option in my case because the stream started out perfectly, then sync shifted by some unknown "random" amount. I can't be chasing that offset down in the middle of a stream, when it may change again. I had audio off by up to 8 seconds last week. Something bad is going on, and I'll have to spend a lot more time on debugging.

Your point is well taken about VLC, but my issue was not that I didn't know about VLC...it was that I thought Media Source would work just fine because it presents itself as if it will and it sort of does. I didn't even think about having OBS use the VLC code to handle this device until I read on this forum.
 
Something bad is going on, and I'll have to spend a lot more time on debugging.

Hence my previous suggestions for a lot of tools to test stability. But given I know you have an usb-c device, and given i know as much about usb related things as i do, i would put the primary focus around that. First things first tho, it would be nice to know if this issue you have replicates itself with other software. Or just simple recordings, while the the usb-c is being used. Hardware conflicts on the same usb chipset should also be checked, dont know what other usb stuff u got connected.
 
Thanks for the tips. Update since last week: I turned off all possible power saving features on USB and for a few other things in the computer. I also turned off the "use custom audio device" in OBS for the BlackMagic ATEM Mini video capture source. Then I created a separate Audio capture source that uses Blackmagic microphone that shows up in the list of mic options in OBS. Yesterday our livestream worked fine with this setup for the first time. Obviously I changed two dials at a time so I can't be sure if only one of them is the real solution, but I don't care about that at the moment. I just am glad it worked better. Will keep trying and see what I find.

I wonder if someone "in the know" can comment as to whether there is any substantive difference in how OBS runs the custom audio device versus having the audio as a separate source but from the exact same device.
 
Back
Top