Analog roundtrip through codec?

Post Reply
KC7RBW
Posts: 159
Joined: Wed Nov 20, 2019 1:23 am

Analog roundtrip through codec?

Post by KC7RBW » Fri Apr 14, 2023 12:06 am

There's a local net on an analog repeater that I listen to that's also bridged to TGIF and when I listen to it via DMR there's no static. This is because the AMBE codec is a voice codec - it encodes sounds that sound like voices and ignores sounds that don't. So that made me wonder if it's possible to shove the analog audio through the codec, encoding and decoding it before sending it to the speaker, thus using the codec as a noise filter.

If possible, we might even use a much higher bitrate than DMR uses (and no FEC) so that the filtered audio is higher quality than DMR (we may not know what parameter to change in the codec calls to do this).

I can think of practical reasons this wouldn't work, like the MCU not being fast enough to both encode and decode, but I do think that a roundtrip through the codec would clean up a lot of static.

That doesn't mean it would always be better audio. If it's hard for you to pick a voice out of the noise, it's going to be harder for software. Most people would want to leave this feature off most of the time. But if you've got a strong signal on a noisy channel it might be really nice.

An alternative would be to run the audio through rnnoise but I suspect that would require both too much space in the firmware and too many cycles on the MCU.

VK3KYY
Posts: 7481
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia

Re: Analog roundtrip through codec?

Post by VK3KYY » Fri Apr 14, 2023 1:58 am

KC7RBW wrote:
Fri Apr 14, 2023 12:06 am
So that made me wonder if it's possible to shove the analog audio through the codec, encoding and decoding it before sending it to the speaker, thus using the codec as a noise filter.
No.

There is no FM Rx or Tx audio path to/from the CPU.

The only Rx audio path(s) are from the Rx to the DMR chip, or on the GD77 from Rx to the speaker amplifier. The DMR chip has no documented functionality to access the raw digitised samples on its input or to send audio samples which for transmission.

The CPU may also not be able to handle simultaenously encoding audio to AMBE and decoding it back to samples, both in terms of the necessary processing power, but also becuase we have to use the official firmware to handle AMBE for legal reasons, and I doubt the way the code was written would allow to separate processes to run at the same time, as they probably share the same memory buffers.

ok1pt
Posts: 167
Joined: Mon Jul 20, 2020 3:38 am

Re: Analog roundtrip through codec?

Post by ok1pt » Fri Apr 14, 2023 4:40 am

KC7RBW wrote:
Fri Apr 14, 2023 12:06 am
There's a local net on an analog repeater that I listen to that's also bridged to TGIF and when I listen to it via DMR there's no static. This is because the AMBE codec is a voice codec - it encodes sounds that sound like voices and ignores sounds that don't. So that made me wonder if it's possible to shove the analog audio through the codec, encoding and decoding it before sending it to the speaker, thus using the codec as a noise filter.

If possible, we might even use a much higher bitrate than DMR uses (and no FEC) so that the filtered audio is higher quality than DMR (we may not know what parameter to change in the codec calls to do this).

I can think of practical reasons this wouldn't work, like the MCU not being fast enough to both encode and decode, but I do think that a roundtrip through the codec would clean up a lot of static.

That doesn't mean it would always be better audio. If it's hard for you to pick a voice out of the noise, it's going to be harder for software. Most people would want to leave this feature off most of the time. But if you've got a strong signal on a noisy channel it might be really nice.

An alternative would be to run the audio through rnnoise but I suspect that would require both too much space in the firmware and too many cycles on the MCU.
Hi!
Generally, using a digital sound filtering is a good idea, it's available in more expensive radios and obviously called "Noise blanker" or "Static suppressor" etc. This technology uses special algorithms to "learn" the background noise and then to eliminate it as much as possible from the input signal. Static suppressors are trained to cut off a short pulses typical for a static discharge.
Audio codecs are there for another purpose - for limiting the bandwidth. Their algorithms don't try to eliminate any artifacts in the signal, they just limit its bandwidth.
The trick is to encode the signal directly from the mike, without any interferences. Small amount of errors during transmission of the signal (which would be represented by noise or static on analog signal itself) will be cancelled by automatic error correction, which is a part of the codec technology. However, when the error level is too high, it may cause erratic output from the decoder, so the signal sounds "robotic" or there are artificial sounds like tweets, noises, hums etc coming out of the decoder instead of the original signal.
Trying to use a codec software to filter the signal already disturbed with noise/static is moreless useless - the codec will try to encode all these additional signals together with the useful signal and because it's not designed to do so, the results would be probably even worse than the original analog signal.
With regards & 73
OK1PT

KC7RBW
Posts: 159
Joined: Wed Nov 20, 2019 1:23 am

Re: Analog roundtrip through codec?

Post by KC7RBW » Sat Apr 15, 2023 2:54 pm

ok1pt wrote:
Fri Apr 14, 2023 4:40 am
Audio codecs are there for another purpose - for limiting the bandwidth. Their algorithms don't try to eliminate any artifacts in the signal, they just limit its bandwidth.
The trick is to encode the signal directly from the mike, without any interferences. Small amount of errors during transmission of the signal (which would be represented by noise or static on analog signal itself) will be cancelled by automatic error correction, which is a part of the codec technology. However, when the error level is too high, it may cause erratic output from the decoder, so the signal sounds "robotic" or there are artificial sounds like tweets, noises, hums etc coming out of the decoder instead of the original signal.
Trying to use a codec software to filter the signal already disturbed with noise/static is moreless useless - the codec will try to encode all these additional signals together with the useful signal and because it's not designed to do so, the results would be probably even worse than the original analog signal.
With regards & 73
OK1PT
Your understanding of codecs is correct for basic codecs like WAV and MP3, but voice codecs behave a bit differently in order to achieve their extremely low bandwidth. Instead of encoding all sounds, they're designed to encode speech sounds specifically. A lot of background noises can't be encoded, so they aren't in the stream of bits that gets decoded on the other side.

It's true that these codecs are not designed to remove noise, and it's true that they don't excel at it. Some kinds of background noises are encoded along with your voice, for example when the noise is similar to noises that are normally part of speech. But as a consequence of how they work, they do filter noise. Encoding noise wastes precious bandwidth.

The voices on the net I listen to are coming in from a variety of inputs including analog repeaters. They aren't encoded close to the mic and many aren't full quieting. You'll hear net control comment on how scratchy a signal is, but you won't hear the scratch net control is hearing.

It's not perfect, and it wasn't designed for this purpose, but it does work the way I described.
VK3KYY wrote:
Fri Apr 14, 2023 1:58 am
No.

There is no FM Rx or Tx audio path to/from the CPU.
Alas. Thanks for confirming, Roger.

I had thought maybe there was one, but filtered such that we couldn't achieve analog APRS, which wouldn't be a problem for this specific application.

ok1pt
Posts: 167
Joined: Mon Jul 20, 2020 3:38 am

Re: Analog roundtrip through codec?

Post by ok1pt » Sat Apr 15, 2023 8:33 pm

KC7RBW wrote:
Sat Apr 15, 2023 2:54 pm

Your understanding of codecs is correct for basic codecs like WAV and MP3, but voice codecs behave a bit differently in order to achieve their extremely low bandwidth. Instead of encoding all sounds, they're designed to encode speech sounds specifically. A lot of background noises can't be encoded, so they aren't in the stream of bits that gets decoded on the other side.

It's true that these codecs are not designed to remove noise, and it's true that they don't excel at it. Some kinds of background noises are encoded along with your voice, for example when the noise is similar to noises that are normally part of speech. But as a consequence of how they work, they do filter noise. Encoding noise wastes precious bandwidth.

The voices on the net I listen to are coming in from a variety of inputs including analog repeaters. They aren't encoded close to the mic and many aren't full quieting. You'll hear net control comment on how scratchy a signal is, but you won't hear the scratch net control is hearing.

It's not perfect, and it wasn't designed for this purpose, but it does work the way I described.
VK3KYY wrote:
Fri Apr 14, 2023 1:58 am
No.

There is no FM Rx or Tx audio path to/from the CPU.
Alas. Thanks for confirming, Roger.

I had thought maybe there was one, but filtered such that we couldn't achieve analog APRS, which wouldn't be a problem for this specific application.
I'm a telco engineer and a lot of time I'm working with voice codecs :-). However, AMBE is a really special one and it's not used in standard telco equipment. I have experiences with a lot of lossy codecs like G.729, G.723, GSM EFR/FR/HR, AMR NB and a lot of others and I know that for example backbground noise can compromise operation of the codec (measured in MOS units) substantially. Typically, old GSM codecs are very bad for noisy signals. It's possible that AMBE does this better, I never did such experiment, so I really don't know how good is AMBE regarding noise suppression.

But let me have an additional remark:
The AMBE codec in OpenGD77 is implemented in software. Radios which can run this SW are always simplex ones, which means, that the codec is either encoding, or decoding, and never does both operations concurrently.
And you suggest to perform encoding and deconding concurrently to suppress the noise. I'm afraid that these CPUs don't have enough power to do it in real time.
Of course missing signal path, as described by Roger, is a real show-stopper, but I believe that there would be a lot of other problems as well...

WIth regards / 73,
OK1PT

KC7RBW
Posts: 159
Joined: Wed Nov 20, 2019 1:23 am

Re: Analog roundtrip through codec?

Post by KC7RBW » Sun Apr 16, 2023 2:39 pm

ok1pt wrote:
Sat Apr 15, 2023 8:33 pm
:.
And you suggest to perform encoding and deconding concurrently to suppress the noise. I'm afraid that these CPUs don't have enough power to do it in real time.
Software doing things concurrently on a single core is just more software making context switches between the two tasks. I wasn't suggesting that it would need to be multi-threaded. If the MCU is fast enough you can run encode and then decode in a single thread, serially, not concurrently. Real time is not a requirement because humans can tolerate quite a lot of latency (it's a requirement for the audio capture, but that part isn't the codec). But it would need to keep up with the raw audio data, which would require more speed than to only encode. Decoding usually requires less than encoding, so not twice as much power, not sure if that's true for AMBE. It's true that hardware engineers will pick the cheapest or least power-hungry MCU for the job, but that doesn't necessarily mean that MCU will also be slow. Sometimes economies of scale mean that there's a much more powerful MCU than is required.

I don't know if the MCU in the radio has speed to spare for this task, which is why I asked.

AMBE is decent at noise suppression, though it's plausible that this is due more to pre-filtering used to improve the performance of the codec than to the nature of the codec.

Several modern noise suppressors are based on only passing voice sounds, instead of on suppressing noise. Amazon's "Voice Focus" is based on methods used in the Speex codec. Zoom's is probably something similar.

In any case, I got the message loud and clear that it's not going to happen in OpenGD77. I asked because it would be a fun experiment, and I knew Roger would know if there were hardware limitations that would make it impossible. There are, so mission accomplished.

Cheers

Post Reply