Variable audio delay on VOTER

AllStarLink
1

Hi All,
Has anyone else experienced this issue?

I run Hamvoip on two RTCM/VOTER systems with a Raspberry Pi 4 as the controller. Both have identical buflen and TX audio buffers.

One is noticeably more delayed that the other (1 syllable vs 3 or 4) which is fine. However if there is a conversation that lasts a while, the delay progressively can get worse from 3 or 4 syllables to 3-5 words or more.

This doesn’t happen if you’re talking to someone on the end of a link, just via the repeater.
I used to run the old voter record function and this would make it much much worse - to the point of 5-10 seconds of delay, so I stopped doing that. Is it just the Pi 4 isn’t powerful enough?

2

Is this a two node system (two node numbers) or one node number with two RTCM’s? I’m guessing the former. HamVoIP has always said their system does not support two nodes.

You could bring both RTCM’s into one node with mix mode if you don’t mind having them linked all the time.

The other option is to run both nodes in duplex mode 3. That lets the RTCM’s do the repeat function. There will be no delay that way. Down side is DTFM will not be muted.

3

Hi Tim,
Sorry I wasn’t really clear.

This is two separate nodes, both running on separate Pi 4’s - HamVOIP.

One is a 2m system, running three VOTER boards and one RTCM (running simulcast too).

The other is a 10m system, running all VOTER boards - one dedicated to the TX and three RX’ers.

Both run their voters over the internet with <30mS pings - so the buflen and TX delays are set the same across both.

The 2m system suffers the variable delay when talking locally via the repeater.
The 10m seems to have a consistent delay of 1 syllable (which I fully expect)

4

So it’s the system with 3 Tx repeaters that is variable. It would be a bit of a pain to swap the configs but it would be interesting to see if the problem follows the Pi’s or the configuration/network.

5

Yes the problem lies with the 2m system.

It isn’t 3 TX, it’s actually 2 TX’s simulcast and two standalone RX’s.

Here is what I have in voter.conf which is the same across both systems as far as the buffers go.

[general]
port = 667
buflen = 250
password = XXXXX

[XXXXX]
Domain = XXXXX,master
Mt.Wellington = XXXXX,transmit
Grey.Mt = XXXXX,transmit ;
Mt.Lloyd-RX = XXXXX
VK7HH = XXXXX
;client4 = pass4 ;
; streams = 67.215.233.178:1667
;plfilter = y ; DSP high pass filter
txctcss = 141.3 ;was 141.3Hz
txctcsslevel = 0 ; Transmit CTCSS level. 35 = 500Hz. Set to zero for off. Normally at 15
txtoctype = notone ; chicken burst
thresholds = 210,130=10
linger=5

You usually notice the effects after a 5-10 mins of conversation between two stations directly on the repeater, the delay gets longer and more noticeable. If it’s repeater > link or vice versa you don’t notice it at all (other than the normal delay you get with Allstarlink running as a duplex repeater)

6

what is your TX buffer set at on the RTCM’s?

I find that if you set it to around 1,000 and the RX buffer at 250 it functions pretty well, only a small blip of audio comes out after you unkey.

I previously ran my simulcast system at 2,000 and 500 and ran into a lot of delay/repeat after you unkey

7

TX buffer is set to 1500.
My latency is under 30mS, so that + 40mS means technically my minimum can be 120 in buflen and set the TX buffer to 480.

I think I did have some consistency issues with one link when I did that.

By the way, the buffers I am using between the two different systems are the same (both RX and TX) but on different internet/IP networks with similar latency though.