waveform api. Can it be used to implement alternative filters?

Wayne, W5XD

I am researching whether its possible to use the waveform API to implement lower latency filters of interest to contesting operation, and am considering only SSB for the moment. To that end, I read through the only documentation I could find, which is: https://github.com/n5ac/smartsdr-dsp. That repo is a working example as opposed to API documentation, and of an application enough different than what I want to do, that I must ask more questions:
The FreeDV sample connects itself to (according to its commentary) a 24K sampler-per-second stream (which it goes on to process in a way that is not of much interest w.r.t my question.) I am first concerned with how much processing latency is already inherent in this input stream. For my current application of interest, if this input stream already has more than about 50msec of latency behind the signal at the RX antenna, then I need not follow this trail any further. Or maybe there are other streams available through the API that this example simply doesn't show?

The only hint I can find about prior filtering is that the FreeDV.cfg file contains a series of command lines of the form "waveform set FreeDV rx_filter" and "waveform set FreeDV tx_filter." According to my reading of the source, those commands are sent to via a TCP socket to a process on the radio itself (which appears to be named "smartsdr" but I am 99% sure that process one running on the radio, and is not to be confused by the eponymous Windows application.) Then I lose the trail--I cannot see where those commands get processed. If I am to follow this trail of implementing a waveform processor, then I am going to have to find out what those commands mean and do.

My overall question is, "can the waveform API be used to implement alternative, low latency, filters for SSB receive?" and, if so, I am going to need to understand more detail about exactly what sampled data streams are available via the waveform API. For starters, its not obvious to me why the FreeDV wrapper (in _sched_waveform_thread) ignores the .imag of the sample stream. Obviously, I would need to know how the radio created that stream in order to understand why the signal even has an imaginary part (i.e. this is a time domain signal). Or maybe it doesn't actually have an imaginary part? But if that is the case, why does the TX side of the processing upsample its 8K sample-per-sec stream to 24K by setting the upsampled .imag = .real?
Thanks for any info.
Wayne

Eric-KE5DTO

The short answer is no, the waveform API in its current form cannot do what you are after (lower latency).  

The longer answer is that the waveform API relies on specifying an underlying mod/demod mode (or using the default) and this existing DSP chain is used when processing the waveform.

Changing up the filters to be lower latency would probably be considered a step lower in our architecture today.  Note that we do adjust the filter latency (length) dynamically in DIGL, DIGU and CW modes depending on the width of the requested filter (wider filter, less latency).

In the FDV waveform, since we are dealing with an audio signal, we really only need 1 channel in and out.  We happen to have 2 and pass them both for FDV in both directions (RX and TX).  This is more of a convenience than anything necessary for processing.

It would be interesting to hear more about your application and the need for less latency.

Wayne, W5XD

Eric: thanks for the info.
The need for filters with a different shape vs. latency tradeoff for contest operation has had some discussion in the forums that I assume you have seen or can find. I found my way into this waveform API question only because I was trying to see if there was an API that would allow an external application to provide a tradeoff that your posting confirms only the Flex team can provide. Like other contesters before me, I request that Flex provide user the ability to select filters that provide lower latency at the cost of shape/bandwidth.
Thanks,
Wayne

Peter K1PGV

Hmmm... Thinking aloud.  Eric wrote:

Note that we do adjust the filter latency (length) dynamically in DIGL, DIGU and CW modes depending on the width of the requested filter (wider filter, less latency).

Could you not select the lowest-possible latency mode (a very wide filter) and to THIS data apply your narrower, lower-latency filter?

I'm just a programmer, and what I know about DSP can fit in a thimble. So excuse me if this is obvious nonsense.

Eric-KE5DTO

Request acknowledged.  Thanks Wayne.