Has anybody used FPC to decode (and generate) FSK modem tones on a VOIP connection? Strictly V.21, don't need the complexity of QAM etc.

Hi Mark,

Mark Morgan Lloyd wrote

Has anybody used FPC to decode (and generate) FSK modem tones on a VOIP connection? Strictly V.21, don't need the complexity of QAM etc.

i haven't ;) but it's interesting: are you just assembling/decoding the ulaw/alaw/choose$codec data into/from
RTSP and sending/receiving through a SIP voice connection?

How real-time does this need to be, to start with?

el es

Real-time enough to simulate a V.21 modem as the backend of a comms program running a proprietary telemetry protocol. Before anybody criticises use of an obsolete modem type, I suggest they consider how long it takes to set up a V.21 call and transfer a few dozen bytes compared with the training time of something more sophisticated.

Leaving aside the call control for the moment, my current thoughts are to accumulate G.711 over UDP into a buffer ensuring this is a multiple of four samples, use x86 MMX facilities to extract the mark/space frequencies, and something like a rolling average to measure which of those is dominant.

I gather you have more data about this protocol to see where it can handle the 'processing time' of the far side receiver, and the rest can be just handled by playing 'recorded audio'.

Not criticizing anything ;)

Leaving aside the call control for the moment, my current thoughts are to accumulate G.711 over UDP into a buffer ensuring this is a multiple of four samples,

g711 can be ulaw or alaw IIRC (g711u g711a) ( not sure if this is relevant for you, but the codecs tend to have separate settings entities and even executables in any audio transcoding software, so I thought I bring this up, https://en.wikipedia.org/wiki/G.711 )

(if g711 codec is transcoded to/from raw audio maintaining the 8kHz sampling rate, then don't you need 26 - 27 samples to fill up the mark/space slot for sending? Receiving, you probably need to interpret your filter/fft output whether you have enough samples accumulated and levels of the frequency peaks detected, and act on that)

The wikipedia page has some (pseudo)code on transcoding from g711 to audio sample(s), maybe it could help ? Doesn't seem very complicated ;)

It's been years since I had anything to do with DSP, unfortunately, but with the FFT running on the sliding 26-sample-long window, and a /reverse/ FFT to produce the 26-long sample from just having a byte or 2 written to an array, the kind of SIMD processing probably won't be very time consuming... and, operating on a fixed size array, would be of fixed-processing-time, which is usually handy.

Just my £0.02p :)
el es

The protocol's no problem, but I need to handle the calls in realtime since processing several dozen a day offline would be... inconvenient.

We've already got conventional modems working over G.711, and my understanding is that the selection between ulaw and alaw is basically a table lookup.

(if g711 codec is transcoded to/from raw audio maintaining the 8kHz sampling rate, then don't you need 26 - 27 samples to fill up the mark/space slot for sending?

Yes, with the length of each sample varying to try to keep the timing right. Still no great problem, particularly since what we send is rarely much more complex than a standard ack/nak.

Receiving, you probably need to interpret your filter/fft output whether you have enough samples accumulated and levels of the frequency peaks detected, and act on that)

FFT is probably overkill. Picking out the peaks is obviously one way of doing it, but the code would run more smoothly (i.e. fewer pipeline stalls) if as much as possible could be run with linear sequences of operations hence- if possible- rolling averages etc.

Thanks, noted. I must admit that I've never dabbled directly with FFT, but perhaps now is the time to start. I need to do a couple of test simulations first to demonstrate that working in the frequency domain is more promising than the time domain (I'm having to fight off the boss's suggestion that I simply time zero crossings).

Just my £0.02p :) el es

Worth more than you think
http://www.bbc.co.uk/news/uk-england-berkshire-33586245 :-)

:)
Thinking about it some more, it could actually be true that FFT/DFT is overkill.

For detection you need 4 specialized discrete band-pass (1 freq pass) filters, checking their output 'power' (side note : moving average can be used as detector on their outputs) and you can use them for sending too - just feed them white noise to the input :)

there are some advantages to that which this email is too short to contain ;)

el es

It turns out that there's a more-or-less off-the-shelf solution in SpanDSP http://www.soft-switch.org/ which is one of the libraries that underlies IAXmodem. It provides a function to process a block of samples, hence a callback to simulate the Rx side of a UART; since it's C (rather than C++) it should be possible to mix it with FPC code.

Cool, bookmarked ;)

Lukasz

That also does G.711 and others.

On unix, I think a soft modem should be accessible via the pty mechanism. But I think this still leaves us with a shortage of (Lazarus) components for writing general-purpose terminal emulators.