[fpc-pascal] Modems etc.

[Mark Morgan Lloyd]

Lukasz Sokol wrote:
> On 20/07/15 10:49, Mark Morgan Lloyd wrote:
>> Lukasz Sokol wrote:
>>> Hi Mark,
>>>
>>> On 18/07/15 17:43, 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?
>> Real-time enough to simulate a V.21 modem as the backend of a comms
>> program running a proprietary telemetry protocol. 
> 
> 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'.

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

>> 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.
>>
> 
> 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 )

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.

>> use x86 MMX facilities to extract the
>> mark/space frequencies, 
>> and something like a rolling average to
>> measure which of those is dominant.
> 
> 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.

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 :-)

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]