Question on auto leveling codec

Haven’t found much on this, but I remember a while back I read something about one of the codecs
for Asterisk that had an internal option to enable ALC (automatic level control). Not sure if this was a
compression codec or not, but it would be nice to use a compressionless one (like ULAW) for use in
my repeater output. Right now I’m using an analog ALC unit between the URI and radio, but it’s
introducing AC hum into the repeater output. The noise is originating in the poorly shielded ALC unit.

Does anyone have ALC working within Asterisk? If so is it hard to make it work in App_Rpt for the

repeater output? I need to keep the input constant because I’m using DSP and CTCSS for squelch,
so output is all I’m looking for.

Thank you.



It would be cool to have a few db of AGC.


On Mon, Mar 7, 2016 at 8:19 PM, John Griffith wrote:

Haven’t found much on this, but I remember a while back I read something about one of the codecs
for Asterisk that had an internal option to enable ALC (automatic level control). Not sure if this was a
compression codec or not, but it would be nice to use a compressionless one (like ULAW) for use in
my repeater output. Right now I’m using an analog ALC unit between the URI and radio, but it’s
introducing AC hum into the repeater output. The noise is originating in the poorly shielded ALC unit.

Does anyone have ALC working within Asterisk? If so is it hard to make it work in App_Rpt for the

repeater output? I need to keep the input constant because I’m using DSP and CTCSS for squelch,
so output is all I’m looking for.

Thank you.



App_rpt-users mailing list

To unsubscribe from this list please visit and scroll down to the bottom of the page. Enter your email address and press the “Unsubscribe or edit options button”

You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.


Well it’s been 7 years since I asked this, and I was wondering if there have been any developers out there that have anything. I’d love to download a codec and try it.

This would probably be relatively easy to implement in chan_usbradio.c. I used to work in the pro audio industry and have a lot of experience with leveling algorithms. Personally I would do a simple algorithm that does 3-6dB of hard limiting - reducing gain whenever any clipping occurs, with a fast attack time and long (1-5sec) release time. I could probably get this working in about 8 hours work, including setting up config parameters to control the feature in usbradio.conf (eg. agctxgaindb and agctxreltimems). Variables could be set up to detect rms and peak levels in the output stream, frame by frame (I believe audio frames are 20mS each both rx & tx), and then essentially normalize each frame to within a gain range of 0 - agcgaindb (which would not increase more than the agcreltime/frame between frames). This could be configurable for rx or tx audio or both. There may be other ways to do this but they likely would not work as well as implementing directly in chan_usbradio.c or a related C file.

I could probably get to this within the next month or two, or maybe someone else could get to it first, but if not and you wanted to get this going sooner LMK. 73

Hi NR9V,

Nice idea.
Unfortunately, I can’t help. My knownledge in C and audio tailoring is near zero.

Did you make any progress ?

It would also be nice to have a tool to measure the audio level on the network between nodes.


I would like to take a look at this in the next couple months but have a few other projects I need to wrap up first. This could be a great feature. I continue to notice on various (ASL-linked) repeaters certain users are easily 6dB louder or quieter than others. With ALC set to add ~6dB of gain by default on each transmission but which then quickly reduces based on peak or rms energy levels being above a certain point within each 20mS frame, or slowly increases gain if significantly below, could smooth things out nicely while being fairly transparent.

BTW another thing that could be useful would be a test utility that could run on a node whereby you connect that node to/from any other node, it looks at all incoming audio and after each transmission from other nodes prints a log message (maybe also on a web page through a simple http json API or app such as AllScan) showing the total average RMS power of the transmission. This would be great for quantifying the true rms audio power levels of each transmission from any node. This could be used similarly to the parrot test tool that provides the “too high”, “too low” voice responses but more precise. It’s simple conceptually, no different than recording the audio stream in a wave editor and running its stats function on each transmission.

An article on Repeater-Builder talks about this in more detail, and proposes an AGC algorithm by which the gain is controlled by a side-chain signal low-passed from 800~1500 Hz, to provide smooth leveling of the overall signal while not noticeably affecting high frequency content and intelligibility.

I’m now experimenting with some dynamics processing algorithms in a radio-less node project, using eg. a ($5) SSM2167 dynamics processor module, and may augment that with an AGC function I add within the simpleusb driver, the idea being with this project to both provide the same dynamics typical of a high-quality analog FM radio channel in a radio-less node but also a smooth and subtle AGC function in the App-rpt channel drivers that could help make audio levels more consistent between any types of nodes.

Just a comment…

The more folks try to fix poor user ‘audio’, the worse things get for ‘network audio’.

Most do not adjust it even close to correct with simply ‘ear’ method. Some do.
Now that there are a few more controls to adjust it locally correct it so allison is not blasting them, their network audio is even worse.

The one thing that is the same in all systems is Allison’s level. If it sounds loud, then your rx audio is to low and tx audio is to hot. Either the setting procedure was in error or the testing equipment is. Likely ‘EAR’.

Funny I never have a issue on any headless system x4 and many others that I have taken down since and I only use ducking over local user input from monitored nodes.

The simple fact is for as long as a user can ‘make it sound right locally’ they go no further.

I doubt poor user network audio will ever be fixed.
But the way to fix it is to get the user to correct the error.

But instead, everyone else shuffles to correct their error.
I am a advocate for a better testing/set-up procedure.

You know, this does not have to be perfect, but it needs to be close.

The first place a auto leveling codec would be required is for the network audio and allow the user to continue his/her own bad habits locally. Since the sources of audio are many more than what they were just 6+ years ago and with USRP sources that could be countless.

From the time analog audio is captured in asterisk it is digital and can not change ‘on it’s own’ till it comes out at some other end. So it’s not the software or the internet affecting it.

To think anyone is going to buy/build something to fix their issues is a huge leap of faith since they will not fix what is already free to fix for the time and perhaps better understanding to do so.
But don’t let my dis-belief stop any development. Seriously, I’m all for progress.

Good Luck !

Hi Mike, thanks for the comments. Some clarifications,

  1. While I’m sure there are some cases where users make their network audio worse when trying to fix their local audio, I do not believe that is generally true. Few users do anything more than set the 2 rx and tx level settings with the tune utility, and using that is a lot more likely to get you closer to good levels than not using it.

  2. The radio-less node design pictured above is a high-quality low-cost full-duplex node that can be built by anyone in a couple hours at a total parts cost of less than $100. I believe these will be very popular and already know several hams building them. I’ll also be selling them fully assembled and configured for hams with less of a DiY inclination. Before doing so however I want to be sure the audio is at least as good as that of a high-quality radio-based node. With an added SSM2167 or similar module to provide limiting and optionally some small amount of compression (configurable with a trim pot) the total parts cost of the complete node with Dell Wyse 3040 microPC, AC adapter or 12V car lighter plug, translucent blue case, DTMF mic, external speaker, CM108AH interface, and audio amp is still under $100. This will be a great way to get on AllStar for many people, similar to my other full-duplex node design – using 2 HTs that can be built for well under $200, with excellent audio quality and 60dB SNR.

As mentioned in my How-To Guides (the one for the Radio-less node will be done in a few days and on my site AllScan.Info), I completely agree with your sentiments on the #1 best way to fix audio, in fact here is an excerpt from my Guide now in progress expanding on this point:

Audio Requirements

A radioless node should have equal or better overall audio performance and features as even the best radio-based nodes. There are really only 2 fundamental differences between radioless nodes and conventional (with radio) nodes, the first of course that one supports wireless analog FM, and the other that a node using radio(s) will have some differences in how the mic audio is processed. FM radios provide well-controlled audio filtering and limiting to ensure that the transmitted RF is not overmodulated, resulting in improved consistency of audio levels and improved intelligibility.

ASL filters Rx audio prior to encoding it and sending it to other connected nodes, and some small amount of compression/limiting/noise reduction may be done in the process of coding the audio in various supported VOIP codecs. Radios additionally do peak limiting of the mic signal to prevent transmitter overdeviation, which also maximizes average Signal-To-Noise Ratio (SNR) and better utilizes the available dynamic range of typical RF communications channels (which can be fairly low in weak signal conditions).

In nearly all pro audio, recording and broadcast applications some processing is done on voice signals which can include filtering out low and high frequency noise, clicks, pops, and sibilance; compressing the signal to give higher and more consistent average power levels; and limiting to prevent overly loud peaks and distortion. Numerous other techniques can also be used to further optimize clarity for a specific voice and application but those are not as applicable to a general node design.

It is important on AllStar and other digital/VOIP-linked communication networks to have consistent audio levels and dynamics from node to node. Otherwise users have to make frequent volume adjustments if one ham has very quiet audio or another has overly loud audio. This is an issue on AllStar and I highly recommend that any time you hear someone on AllStar who is much quieter or louder than average – let them know! Audio levels are very easy to adjust on AllStar and there is no good reason anyone should have improper levels that require everyone else to frequently adjust their volume controls to properly hear everyone in a QSO or net.

Building a radio-less node is pretty simple if you are experienced with computers, Linux, and AllStar. I hope that this Guide will help make the process easier for everyone, while sharing a few optimizations that can result in a node that sounds as good or better than any other node (with or without radios), with excellent audio quality and basic dynamics processing to provide full, clear sound typical of high-quality FM repeaters.

If you have a background in audio/music/recording/broadcasting you could easily achieve the above by running a good quality mic into a mixing console or mic preamp & dynamics processor, then run the output into any radioless node, which would be a good way to get great audio. A simpler approach however is to add a small audio preamp and dynamics processing module to the node, at which point a standard handheld DTMF mic can be used with no extra boxes or cables needed.

Some small amount of gain with fast limiting helps smooth out the raw mic audio coming from a DTMF hand mic and improve average signal levels. A slight amount of compression (e.g. a 2:1 ratio above a threshold of -10dBFS) along with hard limiting of the signal to 0dB FS, ensuring no clipping of the CM108AH ADC should give the resulting signal a similar sound to radio-based nodes.

An article on talks about this in more detail, proposing an Auto-Gain Control (AGC) controlled by a side-chain signal low-passed between 800~1500 Hz to provide smooth subtle leveling while not significantly affecting the higher frequency content and intelligibility. This should be useful not only for radioless nodes but for any node. Some additional slight compression can then be done to increase average signal energy and SNR, and then the signal should be hard limited to prevent clipping the node’s ADC.

The microphone is the first step in the signal chain of any node and if the audio levels and dynamics of the mic are bad, there may not be a lot that a basic dynamics processing module can do to help. The audio may still be thin sounding with poor frequency and phase response and little if any resistance to clicks and plosives. In having tested many studio mics, desk mics, and hand mics over many years, I have never once seen a hand mic that sounds anywhere near as good as a high quality desk mic (such as the Icom SM-10, SM-50, or Kenwood MC-85).

AllStar nodes should always support the use of a DTMF keypad for control functions which implies that a radioless node needs to either use a DTMF mic or integrate a DTMF keypad into the node itself. Getting a mic that already has a DTMF keypad is the simpler option but this greatly limits the mic options to those that have a keypad and output actual DTMF audio rather than serial port button press data. Thus with this node an Alinco EMS-57 is recommended as it seems to be the only widely available mic that meets these requirements, and works with a 5V input allowing it to be easily powered from a 5V USB power source. This is a cheap hand mic however and thus without additional processing the node’s receive audio may not sound particularly great. It might sound fine compared to an average node used with an HT, since HT mics are just as bad as hand mics, but HTs do provide additional flexibility in that any mic can be plugged into the mic jack while the HT front panel still provides a DTMF keypad.

Ideally you could use a high quality desk mic with a built-in preamp and adjustable compressor, and integrate a DTMF keypad into either the mic or the node itself, but that would take some effort and might not be cheap. For those who know the value of good quality audio, this is worth doing, and you probably already have a good mic you use with your HF radios that could be shared with a radioless node using a simple mic switch (eg. an MFJ-1263).

Hi, interesting discussion.

Sorry for the maybe stupid question, but I’m completely ignorant with VoIP.

From your different posts, I understand that once encoded, there is no way to digitaly change the audio level ? Does it mean that VoIP does not “carry” a audio level information ?


Essentially what happens when ASL, Asterisk, or another VOIP system encodes data is it starts with 16-bit PCM data from an Analog-to-Digital converter. Once the signal has been digitized there will not likely be any significant changes to the audio levels. The key to obtaining good audio quality and consistent levels is to get the levels optimal before the ADC. The 16-bit data will have a number of things done to digitally compress the data to u-law, ADPCM or GSM codecs for example, thus reducing the bit rate from 16 * 48KHz = 768Kbps to a small fraction that (eg. 64Kbps for u-law down to < 10Kbps for newer fancier codecs). Some codec formats such as mp3 do also carry level information allowing for lossless gain changes (preventing scaling quantization) but this would probably not be generally useful in the context of ASL, where the important thing is to optimize audio levels before the ADC and before audio coding. The codec is only there to move data over IP as space-efficiently as possible and many different codecs can be used. Then the data is converted back to uncompressed PCM for output to the DACs on other nodes. Some programs such as DroidStar do have AGC functions, which I suspect work on the decoded 16-bit PCM stream. (iaxRpt also has some AGC functions according to its “filters” menu, and I thought I had one of them working at one point, but after further testing it appears iaxRpt does not in fact have any working AGC functionality.)

If a node’s Rx audio does not have optimal audio levels going into the ADC, clipping may occur (which cannot really be fixed later), or if the input level was too low this can be compensated for after the ADC (but this can also increase noise slightly) with a subtle AGC function providing ideally no more than ~6dB of gain range so as to not result in significant audible gain pumping, and/or with AGC in other nodes prior to the DACs.

DroidStar’s AGC works well for fixing inconsistent/low audio and is useful for listening to QSOs/nets when different stations that have inconsistent audio levels. Its AGC has a huge (~20dB) range which greatly reduces dynamic range and results in very noticeable gain pumping, thus sounding more like an over-optimized digital-radio app than an FM repeater. The AGC checkbox does not work on DroidStar, the AGC is always on no matter what you do, in contrast to iaxRpt where the checkboxes also don’t work but AGC is always off. DroidStar probably needs the aggressive AGC since it supports all the digital radio modes, which are known for being all over the place with levels.

Thanks David for clarifications,
It’s now a lot clearer for me.

I’m trying to find a way to mesure the frequency deviation of a remote node, so I can make some tests on the new node I’ve build and still have here on my desk.
I would like to understand what each setting really does a I’m still asking myself what determines the audio level sent to the network.

You have a nice page !
I used these 80m loops for years and they work very well on all bands, even if more locally on the lower bands.

73 Patrick