Idea: Audio treshhold option for high fidelity


I where just thinking.
I have a setup that allow me to set a treshhold on the audio signal, so if the audio signal is above some signal strength it’s opening so you can hear me. If there’s no talking but only noise or a low signal thats dropping below some signal level the signal get auto muted.

Now i think it can be good to implerment also inside high fidelity.
So the simple noise from a fan (if softer then the talk can be muted automatic,

Mute is mabey wrong word, because the microphone keeps open, but only the signal don’t get send to others if its going below some adjustable signal level.


“Gate” is the word for that, more-so than “mute”. But yeah, I concur.


Isnt’ that what ‘Audio Noise Reduction’ does?


Ok, gate. there so much namings on the device. :open_mouth:

Well i have ‘Audio Noise Reduction’ enabled. but i don’t think it’s doing wshat i mean.
‘Audio Noise Reduction’ is mabey to remove noise from the voice ?


I think in this case we can better talk about option named VOX (voice operated switch)

Voice Operated eXchange, is a switch that operates when sound over a certain threshold is detected. It is usually used to turn on a transmitter or recorder when someone speaks and turn it off when they stop speaking


Yup. A VOX (something I’m familiar with from ham radio) is essentially the same thing as a gate (something I’m familiar with from guitar effects processing).

In the case of a VOX on a radio, it actually switches the function of the transceiver from Receive to Transmit when the mic level rises above a configured (usually a “VOX Sensitivity” knob) threshold, and then back to Receive when you stop speaking.

In the case of a Gate, the audio path is still ON all the time (and HighFidelity audio is full-duplex anyway), but your mic’s audio is muted until the level rises above a configurable threshold.

I would argue that a Gate is an essential component of a VOX, but the converse is not also true.

Now, with all that blathering and history behind us, if I wanted this functionality, I would add it externally. I have various audio plugins, apps, and even physical equipment in my bin of crap and wires… I could insert an analog (delay-less) or digital (slight latency, but only on my outgoing signal). I may very well experiment with that, 'cuz now you have me curious. And - it’s an area where I have some expertise (not true of Blender and whatnot).

It does make me wonder if things like NyQuist plugins can be somehow affixed to Interface and/or to the mixer part of the domain-server. I suspect something like that is already supported (haven’t gone searching yet), since reverb can be applied to audio zones of one’s domain-server configs. I wouldn’t presume to try to adjust a gate that would apply to everybody visiting a domain, except as a silly experiment. Your ambient noise floor is surely different from mine, etc.

In any event, thanks for raising a fun (for me) subject.


Then there’s the other end of this - compressor/limiter. Or ALC. It was discussed some in a meeting a week or so ago. And I’d be very interested in finding out if an individual domain-server “owner” could arbitrarily decide that the public library should be a relatively quiet place, and shouting is technologically prevented by a limiter in the domain’s audio mixer thingy jobber. Yes, it would add latency, but it might be an acceptable trade-off to preserve my zen. :slight_smile:


Ther’s one problem, most people don’t add external hardware or plugins.

The rsuklt is that you always will have problems with some open microphones
and hear some noise. That’s why a build in gate with treshold would be good.


Perhaps, though it is still only sometimes a problem, with some people’s mics or environments. We wouldn’t want a universal solution if it causes a universal increase in latency.

I’d be in favor of it being an option at the Interface (i.e. client) end, with a warning next to it that says “Caution, enabling the noise gate will increase your latency.” Some people, who understand what that means, will choose the compromise.

There are things about JamKazam that could be helpful in this regard. As you make changes to settings on your client, it warns you when you’ve landed yourself in a high-latency configuration. Sometimes even blocks you from connecting to others. (This is an idea which is well beyond alpha, in my opinion.)

Only slightly related - I may experiment with something that definitely comes from my ham radio days. A foot switch for enabling the mic. There are many times that I’m just listening along, with my mic’s input on the external mixer turned down. I reach over and dial it back up if I’m going to say anything, then I turn it back down again. It’d be so much easier if I could just step on the pedal whenever I want my mic open.


Im not sure if you really get a visible delay in interface.exe and the stream by only checking if the microphone/line input signal is getting above or under some treshold level.

It’s so far i know it’sonly a few lines of extra code to check on that.