Audio Clip LED feature addition to ASL3

An issue with a lot of users on AllStar (and many other modes) is that they have their mic gain or rxmix gain settings too high and clipping results in the IAX audio, which sounds terrible.

A second issue is that it’s not easy for novice users to adjust their rxmix gain settings without going into the node by SSH, running the tune menu, and having a basic idea of what they’re doing.

I’m now developing a custom USB interface product that will be used initially in radio-less nodes, and am adding signal level and Clip LEDs to make setting levels much easier and more fool-proof for users. However, accurately determining when clipping has occurred, when the CM1xx has an internal mixer and gain boost options in front of the ADC, requires either looking at the digital signal as output by the URI over USB ie. after the CM1xx ADC, or disabling the CM1xx mixer (which would significantly reduce flexibility).

Therefore I plan to add a function to App-rpt that will look at the rx audio stream and any time a sequence of values are encountered that are > ~99% of full scale (eg. a large amplitude square wave), set CM1xx GPIO4 high for ~500mS.

If other URI makers were to also add this single LED and resistor to their PCBs this feature could make setting optimum input levels much easier for everyone. Having been not only an embedded C developer for many years but also an audio engineer for many years I should mention that this is standard procedure for setting levels on many types of sound systems ie. apply a loud input signal until clipping is observed then back off the gain a couple dB. Takes only a few seconds to do. Having a clip LED available also ensures that even after initial calibration that if something changes or someone starts talking too loud or too close their mic, or uses a different mic or different radio, the clip LED can alert them right away of an audio level issue.

2 Likes

Sneak preview of a custom manufactured replacement for the AllScan ANR100-A Radio-Less Node Audio Module, putting all parts on one PCB while adding more status LEDs, making the mic gain controls and Line Out jack standard features, and adding internal switches, jumpers, and trim pots to support fine-tuning of all preamp, AGC and filter parameters.

Update: Should have prototype boards in the next week. This incorporates a clip detector on the internal audio levels (since most nodes will have older ASL/HV/DVS/etc versions), that also looks for low to high transitions on GPIO4, thereby supporting clip detection both before and after the ADC.

Update: My ADC Clip Detection feature has been submitted to ASL3: Add RX Audio Statistics and ADC Clip Detection feature. This adds a n… by davidgsd · Pull Request #396 · AllStarLink/app_rpt · GitHub

UCI120-rendering-500x448

2 Likes

what sort of headroom are you putting in?

Old school (NPSPC) was something GE/Ericsson called average voice test tone or AVTT. They ran -10dB, which would be around 30% of max deviation or 1.5kHz in a 5k-dev system. And at that level you’d still expect some light clipping about 3% of the time.

In other words, there’s usually “some” clipping in normal narrow FM channels at decent audio levels. It’s certainly possible to run even MORE headroom (-20dBFS) but that results in rather low audio…

And there’s AGC in part of the IAX code? I was not aware that is a feature. The feature I used a lot in Audacity is “soft limiting” usually preceeded by AGC (or any number of compressor steps.)

TNX
kd6ovs

(the one feature I wish ham FM radios had is “modulation limiting”. That’s a standard feature in commercial land mobile stuff from motorola/EFJohnson/GE/etc… (basically an audio ALC).

AllStar was originally intended for use with radios but over time expanded to include radio-less nodes and apps such as iaxRpt, DVSwitch Mobile, RepeaterPhone, etc. The downside of nodes/apps that don’t use a radio is that they may not benefit from the filtering, limiting, compression, etc. that radios provide. I don’t know if any of those apps do anything at all to the mic audio but my guess is they just send it over IAX exactly as it was received. Smartphone apps can have good audio because the phone hardware and possibly OS most likely does some AGC and limiting (otherwise speakerphone conversations would have very inconsistent audio levels). Those apps are however no substitute for a real node. They give very little control over how the node works, don’t support dashboard apps or scripting, and do weird things such as in the case of DVSM putting out occasional tones on your outgoing audio even if you have no such setting enabled. And these apps are not open source or easy to modify or extend. iaxRpt is ancient but a nice PC app for test/audio capture purposes, but in general a real node is the only way to go.

In VOIP apps I believe the goal is generally to use the full dynamic range of the codec, ideally with peak levels near 0dBFS with hard limiting to prevent clipping. The simpleusb channel driver does not do limiting or any dynamics processing and thus can give full dynamic range, whereas usbradio driver in my experience does do limiting and its outgoing IAX audio rarely goes above -10dBFS. Maybe that’s helpful for preventing clipping of someone else’s radio, but that someone may also be getting IAX audio from 20 other people, several of whom may have clipped audio. Limiting done in a channel driver won’t fix audio that was already clipped in an ADC.

Thus the 1st Law of any VOIP communications system has to be Thou Shalt Not Clip The ADC. Everything else is a secondary detail since it’s not easy to turn square waves back into sine waves. Clip restoration could be a useful feature but probably a better approach to prevent clipping (for that small number of users who violate the 1st Law) is to automatically reduce the rxmix settings when clipping is detected. A few clips might still get through but would then be quickly brought under control, and better to make good use of the CM1xx mixer section than to try and restore clipped audio which has artifacts and won’t sound as good as audio that wasn’t clipped in the first place.

Nodes that use radios are probably less likely to have clipped audio because of the limiting provided by the radio (if the node was properly set up and levels optimally adjusted), then at that point as different other radios are used to talk into the node audio levels may go up and down a bit but should not result in ADC clipping. Thus an FM radio channel makes a good hard limiter, and the sharp low-pass filters can significantly reduce distortion artifacts. But a radio may still not help much if a user didn’t set their levels right and has the rxmix setting just a little too high or is running a speaker level input to the ADC that’s going to clip it even with rxmixset=0.

It’s interesting to look at the details of how various radios process, filter and limit the audio. Some manufacturers have done some great things there. But at some point these signals have to go into an ADC and whether the signal is coming from a $5K radio or a diy radio-less node with a $5 counterfeit mic, if the ASL rxmix setting is too high clipping will result and the audio will sound terrible. No URI can prevent users from making incorrect settings. A user who has expertise in commercial radio systems is much more likely to get their levels right, but I frequently hear people who are a bit too loud and have clipping artifacts in their audio.

All the CM1xxx IC variants have an ADC input range of 2.88Vpp but that’s only meaningful if the rxmixer setting is set to the minimum. CM1xx’s do have an option (MSEL pin) to disable the internal mixer, and this could be perfect for the UCI as it should make it much easier to properly match the rest of the levels on the audio interface analog circuitry if the input and output ranges of the CM1xx are fixed rather than having a 40+dB adjustment range, though having fixed gains can be limiting in some situations. For the UCI120 I’m going to take a closer look at disabling the CM1xx mixer because unlike all URIs, the UCI DAC goes into a volume control and then speaker amp with known gain, and the ADC is fed from a mic preamp AGC IC that has a known output range and is precisely matched to the ADC input range. Thus it may be easier to properly match the levels in the analog circuitry and never need to rely on the CM1xx internal mixer (which in the context of an ASL radio-less node does nothing more than provide extra amplification for cases where someone was not able to get 2.8Vpp into the IC, or in the case of Tx audio, attenuation for cases where someone’s speaker amp has too much gain). URIs in contrast have to accommodate all sorts of different radio systems and I/O levels from 10’s of mV to many Volts.

Another question is what standards / best practices might exist with Asterisk / IAX / VOIP, from my experience it’s no different from digital audio in general where you observe the 1st Law above and make best use of available dynamic range, and Asterisk doesn’t seem to do anything to the audio other than send out whatever data came in from the ADC, as I’ve confirmed from capturing the direct audio output from iaxRpt.

With Asterisk being a big fancy phone system you’d think it would have some sort of AGC function, and you would be right – AGC - Asterisk Documentation – just looked it up now, so that’s another thing on my list to investigate. (Now that ASL3 has brought Asterisk up-to-date these sorts of features should be easier to use.)

Usbradio does some rx audio limiting (and I would assume on tx audio also), which should be helpful to smooth out IAX levels a bit, and simpleusb should probably be updated to do the same thing for consistency and because simpleusb applications are probably even more likely to benefit from some leveling/limiting since they’re less likely to be using higher-end radios. But in terms of overall signal chain the ADC is the first and most important point which is what I’m focusing on now and then once that is well under control I’ll be looking at further optimizations in ASL and Asterisk.