We have multiple nodes connected at all times, is there an Auto AGC for ASL3 that we can set to help with many different audio levels.
If not mabe a future idea.
Thank You
Sal N6SPD
Asterisk provides an AGC function that can be enabled in extensions.conf, however it appears that Asterisk has to be recompiled to add the libspeex module for this to be supported. It was on my list to try this and see how it works, but it might take awhile as I am not clear on how to edit the app-rpt dialplans in extensions.conf to enable the AGC function on incoming and outgoing connections. I could probably figure it out with some experimentation but one of the ASL devs with more Asterisk dialplan experience could probably figure this out in about 5 minutes. I have opened an enhancement request for this feature - Support Asterisk AGC() Automatic Gain Control function · Issue #695 · AllStarLink/app_rpt · GitHub
Yes it is called having Hams check their audio levels before they connect. on allstar you can connect to 2 different nodes. 40894 and 55553. on echolink they can use the test server at 9999.
In theory I've always been a proponent of letting people know when their audio levels are too high or too low, but the truth is there are some random people with who-knows-what hardware/apps, sometimes bridging from digital modes, and to try to get them all to correct their audio levels is not as easy as it sounds. No one wants to be the audio police interrupting QSO's/nets to tell people their audio needs adjusting. Thus if something can be done with some simple software options to address these outliers it is worth some investigation. OP and others who have mentioned this issue in the past would not be mentioning it if it was as simple as all users knowing to regularly do a parrot test. The users who most need to do that kind of test are exactly the ones who fail to do it or just have no perception of what good audio should sound like.
So, I'm all in favor of audio processing options on ASL, provided that they can be implemented sensibly with reasonable defaults, but this has me wondering about something.
At what points in the chain would you want processing to exist?
If you are running a repeater with voting receivers, would you want the RX of all receivers to have limiting, if nothing else, so as not to bring up the noise floor, but clamp down when someone overdrives their transmitter?
Would it make sense to have separate processing for RX and TX on a node done in such a way that they don't fight against each other, regardless of what channel driver is being used?
What about processing audio sent from your node, either through IAX, USB, voters, USRP, EchoLink, etc. to other IAX connections?
Or, just forget all that, and only process TX audio sent by your node, such that anything you do doesn't affect anyone else upstream?
I operate a multi-mode system, and I've found that using DVSwitch's implementation of AGC for the digital to analog conversion from DMR and DStar does a pretty good job of "normalizing" the amplitude from digital stations, unless they're way too quiet, under the threshold, or way too loud, in which case the AMBE vocoder breaks other stuff first. I have actually sent ASL's output through USRP to Analog_Processor, which has the same AGC as Analog_Bridge, then monitored through the other side of that, and it can help, but of course, if misconfigured, it can also raise the noise floor significantly, especially with less clean analog signals.
Letting people know about their audio is exactly what us amateur radio operators are supposed to do. That is part of the policing of the bands. Making sure they are on frequency and inside their bands and letting the others know what their radios are doing. You also have to realize that a license test for ham radio does not tell you how to operate the radio nor to make the audio adjustments. That should be taught to them by explaining it to them. Take the time to teach, so others can learn. Too much everyone wants the quick and easy route, when in ham radio nothing is as easy as it sounds.
Minimal AGC/Limiting ideally would be done at each step along various audio paths ie. the outgoing IAX Tx audio from each node, audio received at any repeater RF receiver, and since this will not be done in all nodes implies it should be done in IAX Rx audio also. If a sonically transparent algorithm is used that does not alter signals within normal volume ranges, there will be no signal degradation from running the algorithm at each step along various nodes and interfaces eg. originating node or repeater receiver, potentially intermediate hub nodes or mixers, and in destination nodes. Such an algorithm could for example provide fast limiting eg. above -3dBFS peak, clip detection and filtering, and slow AGC (eg. +1dB/sec below -20dBFS rms). Thus signals would not be altered if within optimum volume ranges ~ -9 - -20 dBFS rms. This is easy to do in C and would be easy to integrate into the channel drivers (ie. initially only processing USB Rx/Tx audio but not IAX audio). But if there is already a way Asterisk can do something similar that would be simpler.
On our systems I usually berate them (in a friendly manner, natch) and tell them to either come by or ship their radio to me so I can tune it...
instead of tuning it show them how to adjust it. so then they would know more about it and can pas on what they learn.
Oh, I most certainly do. (you've no doubt seen the theater scene in A Clockwork Orange, I trust... 
)