Apache Labs Community Forum

Specifically, does increasing or decreasing the SSB TX Filter Size have any effect on TX audio latency, when Low Latency is the Filter Type selected (see screenshot)?

tia,
Mark

I noticed you also posted here Mark. We discussed it extensively over on discord, but this video covers it.

The test in the vid includes the full chain latency, but, that part is consistent so can be ignored. All that is changing is filter size when fixed in low latency mode, and shows ~64ms difference when changing filter size from 4096 to 16384.

https://youtu.be/SWGS4uC1L24

and via another radio https://youtu.be/9JgJwrGfjX8

73

There is less than 10 ms of delay difference between the smallest and largest "low latency" filter sizes. The 60 ms difference you measured, Richie, is probably an artifact of how you measured it.

Note that the "low latency" filter type is more properly termed "minimum phase", as opposed to the "linear phase" filter type. But Warren thought that "low latency" was a better description for most users.

In your video, the selected transmit profile is "RagChew", which implies some sort of audio processing going on. Because the group delay of a minimum phase filter is highly frequency dependent, it's possible that whatever audio processing is in use for the RagChew transmit profile may be causing some changes in frequency content. The rather stretched response coming from the MON channel is also indicative of some changes.

The finger snaps used as a stimulus also result in a somewhat inaccurate leading edge to measure from.

When Warren was initially developing the low latency filter option, in order to get accurate and repeatable measurements I had to use a pulsed tone generator directly into the microphone input. And, most importantly, ALL audio chain processing was disabled, including the leveler. This resulted in the ability to measure each cycle of the input and output audio very precisely.

You might try this again without any audio processing enabled (DIGU or DIGL work great for this), and PS should remain off as well as it will otherwise distort the MON output, which comes directly from the DAC data stream.

The latency of the linear phase filters is easy to calculate. Linear phase latency (aka delay) in milliseconds = (n-1)/2/48 where n = the length (aka size) of the filter, and the 48 represents the audio sampling rate in KHz. Thus the latency of the linear phase filters range from 10.7 ms to 170 ms. This is a far cry from the delay through the low latency filters, which range from 1.7 ms to just a few more milliseconds at the maximum size (I can't remember the exact number, but it's less than 10).

Thus the low latency (minimum phase) filters are ripping fast, but they do generate some ringing on the leading and trailing edges of the signals flowing through them. You can visualize this plainly when doing something like receiving radiofax signals as you can see "ghosting" of the image. Many people with sensitive ears can notice this as well, particularly CW operators. And they have group delay (different delays vs. frequency) which some people might also be sensitive to.

On the other hand, there's essentially no ringing or group delay in the linear phase filters, but they are pretty slow. However, when you consider that the 1024 length linear phase filter is many times sharper than the filters in any other radio other than the Flex, then it's diminishing returns to go any longer than 1024, and an 11 mS delay is easy to live with.

There is less than 10 ms of delay difference between the smallest and largest "low latency" filter sizes. The 60 ms difference you measured, Richie, is probably an artifact of how you measured it.

Well it does seem to show a different latency, when the type is fixed at minimum phase (low latency) and the buffer size is changed as I will outline and show below. (edit: also see Warrens comments in Edit2 below)

Note that the "low latency" filter type is more properly termed "minimum phase", as opposed to the "linear phase" filter type. But Warren thought that "low latency" was a better description for most users.

I mentioned the term minimum phase in the discord discussions earlier, but kept things simple here as not add additional confusion. A few millisecionds due to the finger click method does not explain the 64ms/81ms difference observed each time. I can create a pulse and inject that instead of the finger clicks, but as this was an ssb enquiry from Mark, most likely using phone, then I figured that would be close enough.

My tests shsow that there is indeed a difference, testing via mon, or from another reciever.

This is a test vid, as per your suggestion, using DIGI and changing just filter size, and keeping the filter set to minimum phase (low latency), which results in an increase of 81ms when changing from 1024 to 16384 filter size.

https://youtu.be/Rc7NlQ1KSGQ

Edit: also tested with 4096 + 16384 in digi, the difference being 64ms matching my previous testing above.

Edit2: Warren has got back to me regarding the results, and he tells me that there is one filter in the chain that is not converted from Linear Phase to Minimum Phase, specifically the CFIR (compensating fir) filter. It is left in linear phase so additional filter size will introduce latentcy. He points out that difference in number of taps = 16384 - 1024 = 15360, will give an aditional latency of (15360/2 samples) / (96000 samples/sec) = 80 msec, which is exactly what I measured (81ms) and very accurate considering I was just using a clicked finger. I will be performing tests with the G2 as the TX radio tomorrow to check perforance as it has a different cfir implementation.

Edit3: The G2 tests are in, and the increase in delay is the same. The wdsp CFIR processing is not being turned off by Thetis at the moment which would explain it, and there might be reasons why it has been left on. Warren is investigating.

Edit4: Warren let me know that the G2 still uses the software CFIR implmention as issues arrose during testing of the fpga firmware implemented solution during G2 development, hence why we also see delay.

73

ramdor wrote: Wed Jan 21, 2026 8:21 pm I noticed you also posted here Mark. We discussed it extensively over on discord, but this video covers it.
.
.
73

Richie,

I do truly appreciate all of your focus on my question over on Discord, in fact I had forgotten all about ever having also posted the question over here until now.

The only reason I even posted the same question here is because it was well into the next day after my post on Discord and I still hadn't seen any reply over there, so I was hoping that perhaps a wider readership here would increase the chances of someone seeing my question.

Best regards,
Mark

ramdor wrote: Wed Jan 21, 2026 10:47 pm
Edit2: Warren has got back to me regarding the results, and he tells me that there is one filter in the chain that is not converted from Linear Phase to Minimum Phase, specifically the CFIR (compensating fir) filter. It is left in linear phase so additional filter size will introduce latentcy. He points out that difference in number of taps = 16384 - 1024 = 15360, will give an aditional latency of (15360/2 samples) / (96000 samples/sec) = 80 msec, which is exactly what I measured (81ms) and very accurate considering I was just using a clicked finger. I will be performing tests with the G2 as the TX radio tomorrow to check perforance as it has a different cfir implementation.

Edit3: The G2 tests are in, and the increase in delay is the same. The wdsp CFIR processing is not being turned off by Thetis at the moment which would explain it, and there might be reasons why it has been left on. Warren is investigating.

Edit4: Warren let me know that the G2 still uses the software CFIR implmention as issues arrose during testing of the fpga firmware implemented solution during G2 development, hence why we also see delay.

My apologies, I had completely overlooked the presence of the CFIR equalization filter stage. In Protocol 1 this filtering is located in the firmware. In Protocol 2 it was moved to the software (Thetis) because P2 firmware placed a strain on FPGA utilization. Thetis knows what to do based on whether it detects P1 or P2 type firmware.

Looking at the P2 signal processing chain up to the baseband digital IF stage (it's the digital IF data that streams over the Ethernet):

The receive signal processing chain is ADC --> CORDIC --> CIC Filter --> Baseband IF --> Ethernet, and all of this is in the FPGA. Warren tells me there is no CFIR stage on receive because the CIC Filter response is quite flat.

The transmit signal processing chain is Baseband IF --> CFIR --> Ethernet --> CIC --> CORDIC --> DAC. Everthing to the left of "Ethernet" is in Thetis, everything to the right is in the FPGA.

The CFIR, CIC and CORDIC functions together perform the direct digital up and down-conversion functions in the radio. It is easy to overlook these important functions as they are essentially hidden from the user. Most importantly, as Ritchie points out, the CFIR size (length) is set to match the selected transmit passband filter size.

The passband filtering, which is performed in Thetis, has less than 2 milliseconds of latency with the low latency filters regardless of their length. As previously noted, the delay through the linear phase passband filters in milliseconds is (n-1)/2/48 where n = the filter size.