Changing audio delay in Duplex mode (relatively long delay, even close to a second)

[oh1sdr]

Hi,

We are experiencing quite long delays in audio, but it seem to be changing quite rapidly. How we see this, is that you can hear a part of your own transmission after releasing PTT. The delay is up to one second, which seems really long. We are using CTCSS in auto mode. The delays related to TX and squelch has kept in minimum. CPU usage is always below 20% and usually below 15%.

SVXlink 1.5.99.17 Raspberry Pi 3 with Raspbian Stretch Light Sound Card USB CM108 chip based, using ALSA

73 de Janne OH1SDR

[f5vmr]

Hi, This is perfectly normal particularly if you have elected to suppress DTMF and 1750 Hz tones. It is perfectly normal in repeaters with these suppression techniques, although I would admit passive filtering is faster. You can comment out these settings but be prepared to hear tones repeated, but the throughput will be faster. F5ZGM-R experiences about 400 Milliseconds of delay, as I have elected to suppress tones, as there are some fidgety people who enjoy a blip. Your current SVXLink installation is now obsolete. Chris F5VMR/G4NAB

[oh1sdr]

Hi,

Tnx for the answer Chris! Didn't realise that the filters will make so much a difference. Gonna have a test immediately!

73 de Janne OH1SDR

[oh1sdr]

Hi,

Turned DFMT_MUTING and 1750_MUTING off, but don't see much of a difference. Sometimes I hear echo of my self, sometimes not. It's quite interesting why the delay seem to be changing so much. I'm offsite now, so obviously the testing is quite empirical and I released PTT immediately after my last TXed words.

To me, the delay seems much longer than 400ms. Actually, this is the only bothering thing, really great SW.

73 de Janne OH1SDR

[sm0svx]

DTMF suppression will add 40ms delay, 1750Hz suppression 75ms, squelch tail elimination will add as much time as you set it to. The largest delay set the max so if both 1750Hz and DTMF suppression is set the total will be 75ms. If you use a receiver voter it may add some delay depending on configuration.

What can cause a bit larger delays is if there is a sound clip playing and you start talking in the middle of it. It shouldn't be a second though.

Sound hardware or drivers with unusually large buffers could cause problems but I guess the one you use is pretty mainstream. But really, if the hardware and driver is behaving as expected the buffer sizes set by SvxLink should be respected.

There's always a little bit of audio delay but it shouldn't be much, like 100ms.

Have you changed a lot of configuration or are you pretty much using the default?

[oh1sdr]

Hi Tobias,

I switched the DTMF and 1750Hz suppression off and the delay was decreased. We don't use RX voter. The conf file is heavily chanced.

The repeater site is new (almost 200m ASL, even you might hear it with tropo), and I've spent all of my free evenings there struggling with a local interference. It seem to have close to 100Hz FM components and I think this might be one reason for the strange audio behaviour time to time, since the CTCSS at this area is 103.5Hz.

Besides the changing delay, sometimes fraction of sentences are repeted after several seconds. Could it be the interference that is mistakenly detected as CTCSS, or is blocking CTCSS time to time?

At best times the delay is around 100ms now.

73 de Janne OH1SDR

[sm0svx]

For sure an interference containing a 100Hz frequency component will cause problems. I don't see how that would cause audio repeating several seconds later though. I do not recognize that behavior. Have you tried using different brands of audio hardware?

Another thought about delays, you say you have a heavily modified config. If that involves TCL modification that run code that takes time, like running some external utility that fetch something from the Internet, that would cause audio interruptions and delays since SvxLink is single-threaded. Any SvxLink activity will stop while processing a TCL event.

[Dloranger]

@oh1sdr

on your raspberry pi, make sure that w1_bus_master1 (1-wire temp sensor) is not running at all. This process has caused me multiple issues, one of which is severe chopping audio and unpredictable PTT delays.

run the following command on the console to check on it.

top -d 0.25 | grep w1_bus_master1

if its running you will get a bunch of filtered results and you can watch the processor get heavily loaded while its running. The cpu usage spikes seem to occur on roughly 30 second intervals but this is observational so timing estimate may be off somewhat.
To disable it, edit /boot/config.txt and remove/comment out the dtoverlay that references it and reboot the pi.

Hope this helps with your issue

[Dloranger]

One additional thought to check as well as the w1_bus_master is to change the sound card clocking rate. We have observed on the SGTL5000 codec chipset ("fe-pi sound card) that not using a sample rate of 48000 causes audio problems as well, you might be running into something similar there as well

[oh1sdr]

@Dloranger tnx for the input! Important things to check out when having these kind of issues.

@sm0svx We probably made some kind of a break through. Changing from CTCSS mode 0 (estimated SNR), to mode 3 (estimated SNR + Phase), solved all of our problems. The fragmentation problem hasn't occurred even once, and also the audio delay is now stable. Also, the mode 3 seems to be working just nice!

73 de Janne OH1SDR

[sm0svx]

This seem to have been resolved. Closing.