Mute with RNN Noise Suppresion causing render time to spike?

Y

youngmellz

New Member
Hi all, when I put my mic on mute it causes my render times to go through the roof. I’ve narrowed it down to the Noise Suppression filter on the mic and RNNoise is the issue, however when the mic is unmuted everything looks great and times go back to normal. I can use Speex without any spike in render times, both with mic on mute and unmute but the moment I use RNN and mute mic render goes up. When I unmute it’s normal. How can I fix this and what exactly is happening? There is no sound going into mic so how can render times increase? not sure if the log will help but here it is.

https://obsproject.com/logs/xiNIli3nDGZWJ2zz
 
Please be aware that your system is below minimum specs for OBS to run and may be too underpowered to livestream. There are no recommended settings we can suggest, but try the Auto-Config Wizard in the Tools menu, don't change anything and then close and re-open OBS. You may need to upgrade or replace your computer for a better experience as OBS is running on an Intel iGPU. This hardware is generally not powerful enough to be used for both gaming and running obs. Situations where only sources from e.g. cameras and capture cards are used might work.

1. You have the following third-party plugins installed:
  • vertical-canvas
  • source-clone
  • obs-composite-blur
  • gradient-source
  • StreamDeckPlugin
  • obs-stroke-glow-shadow
  • advanced-scene-switcher
  • obs-advanced-masks
  • aitum-multistream
  • move-transition

    Remove any of those that are not 100% necessary for the main content on your stream/recording.
2. Prior to opening OBS, close any other programs that are not 100% necessary for the main content on your stream/recording.
3. Your log contains no recording or streaming session. Results of this log analysis are limited. Please post a link to a clean log file.
To make a clean log file, please follow these steps:

1) Restart OBS.
2) Start your stream/recording for at least 30 seconds. Make sure you replicate any issues as best you can, which means having any games/apps open and captured, etc.
3) Stop your stream/recording.
4) Select Help > Log Files > Upload Current Log File. Send that link here.
 
Here is the log file of literally just a scene of the mic source and RNN noise filter applied. there are no other sources added. I physically muted the mic several times NOT via software. Mute was via hardware. Not sure if log will show that but here is link https://obsproject.com/logs/zSd32rZI91s9xTAv. Computer will run stream perfectly without RNN enabled so although it is low performing that is not the cause for mute spiking render.
 
I don't think your PC is capable of doing a horizontal and vertical stream, at least at 720 30 FPS. Tell your Tiks to hold their phone sideways.

Your log contains streaming sessions with dropped frames. This can only be caused by a failure in your internet connection or your networking hardware. It is not caused by OBS, but OBS can help. Follow the troubleshooting steps at: Dropped Frames and General Connection Issues. Start with enabling Dynamic Bitrate in Settings > Advanced > Network.
 
Perhaps you are misunderstanding my issue. My stream runs smoothly without any frame drops. However when activating the physical mute button on my mic while RNN noise cancelation is active in filters, render times begin to spike and frames drop. This is not due to many sources being used at once because i have created a new scene collection with only a mic source and RNN noise cancellation active and i can replicate the issue. I am also not streaming vertically, i just use the backtrack feature. The mute issue still occurs when the vertical dock is closed/disabled.
 
Have you looked at overall OS CPU utilization when hitting the physical Mute button?
There could be a driver behavior 'issue' with RNN noise cancellation causing a system resource impact (or ??) when trying to process a signal with no input.
I'm not familiar with RNN Noise cancellation, but the above list of plugins would seem to indicate this isn't an OBS Studio specific plugin, but something you configured at Operating System level, correct?
 
Your log clearly indicates lagged and dropped frames:
Code: 
16:17:40.896: Output 'adv_stream': Total frames output: 2066 (2219 attempted)
16:17:40.896: Output 'adv_stream': Total drawn frames: 1624 (2357 attempted)
16:17:40.896: Output 'adv_stream': Number of lagged frames due to rendering lag/stalls: 733 (31.1%)
16:17:40.896: Output 'adv_stream': Number of dropped frames due to insufficient bandwidth/connection stalls: 153 (6.9%)
16:17:40.897: Video stopped, number of skipped frames due to encoding lag: 735/2325 (31.6%)
16:17:40.902: ==== Streaming Stop ================================================
16:17:44.542: Output 'Vertical Backtrack': stopping
16:17:44.542: Output 'Vertical Backtrack': Total frames output: 2094
16:17:44.542: Output 'Vertical Backtrack': Total drawn frames: 1469 (2202 attempted)
16:17:44.542: Output 'Vertical Backtrack': Number of lagged frames due to rendering lag/stalls: 733 (33.3%)
16:17:44.543: Video stopped, number of skipped frames due to encoding lag: 734/2200 (33.4%)
 
Lawrence_SoCal said:
Have you looked at overall OS CPU utilization when hitting the physical Mute button?
There could be a driver behavior 'issue' with RNN noise cancellation causing a system resource impact (or ??) when trying to process a signal with no input.
I'm not familiar with RNN Noise cancellation, but the above list of plugins would seem to indicate this isn't an OBS Studio specific plugin, but something you configured at Operating System level, correct?
Click to expand...
Yes it seems like cpu usage by goes up 15-20% when the mic is physically muted however it’s still only using about 30-40% total cpu. All drivers seem to be up to date. I have restarted obs in safe mode and I am still getting issue. I have added a test scene collection with only the mic added (with RNN noise suppression filter) and it still occurs so this issue HAS to be coming from the base OS or base OBS build and since it was in safe mode, it’s not a plugin issue. Of course I could just not use the physical mic mute but that is a bit inconvenient.
 
Physically muted effectively means *replacing* the signal with silence. There's no such thing as "no signal" at that point. There's *always* a signal, and a physical mute simply forces that signal to be silent. A lot of software mutes also work that way, but not all.

So you might have found a bug in RNNoise, or just a quirk of how it works, in that a sufficiently noiseless input causes it to look hard enough for *something*, that it appears on the CPU usage meter.
 
AaronD said:
Physically muted effectively means *replacing* the signal with silence. There's no such thing as "no signal" at that point. There's *always* a signal, and a physical mute simply forces that signal to be silent. A lot of software mutes also work that way, but not all.

So you might have found a bug in RNNoise, or just a quirk of how it works, in that a sufficiently noiseless input causes it to look hard enough for *something*, that it appears on the CPU usage meter.
Click to expand...
Thanks for your reply. This is a great explanation, I think RNN is more dynamic in realtime adjustments so it is possible that it could be a bug. RNN also doesn’t have any adjustment dials which supports this (everything could be computational) speex however does have an adjustment dial which may just use a flat value across all frequencies and acts more as a low pass or high pass filter. Do you have any mics with physical mutes buttons? Is there any way to submit this to developers for investigation? By the way the mic is the Maono DGM20
 
youngmellz said:
Do you have any mics with physical mutes buttons?
Click to expand...
There are a LOT that do, and they're annoying for live sound engineers! Inevitably, the mic "doesn't work", because the mic *itself* gets muted. If there's not a dedicated live engineer, *then* it can be useful. If there is, tape them all on, or don't even have that switch at all on the mics.

youngmellz said:
By the way the mic is the Maono DGM20
Click to expand...
Oh. Soft mute, and USB only. That doesn't necessarily mean that it works any differently, except that its mute probably *is* true silence. All digital-zeros. That could be a special edge-case.

Analog mics with mutes, simply short out the signal. You still have analog noise that gets in after that point, and that might be enough to keep a noise reducer from going nuts.
 
You must log in or register to reply here.
Back
Top