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, 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) > 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 :) el es _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal