[fpc-pascal] Modems etc.
el.es.cr at gmail.com
Mon Jul 20 16:15:45 CEST 2015
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'.
> 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,
(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)
> 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.
Just my £0.02p :)
More information about the fpc-pascal