Hi Kristoff,
I am back where I have a keyboard now :-)
I would like to hear from David regarding whether any bits of VQ are
"more sensitive" than others, or if it is the case that if we get an
index off by one bit we go arbitrarily far from the intended signal.
That was my suspicion but maybe I'm wrong.
I propose to code a system that makes it easy to insert an arbitrary
interleave and/or FEC function. The system itself is rather more fancy
than you might have planned, but it will make it dead simple to
experiment with FEC and interleave.
So, I propose to provide:
A coroutine interface that makes it as simple as possible to insert a
chain of arbitrary functions that transform the bitstream.
For each transformation, a function is provided for transmit and a
second function for receive, and an initialization and tear-down
function are provided for transmit and for receive separately. So, that
is 6 functions per transformation.
A pre-defined C struct is used to pass in all 6 functions, and their
name, as one argument.
Each initialization function takes its input frame size and input data
rate as an argument at initialization time.
Each transformation function accepts a number of bits which is its
"local frame size". This can be as small as 1 bit. From time to time the
function emits some number of bits, but it does not have to emit bits
every time it is called.
Each initialization function will allocate all memory resources that
will be used by the transformation function, except for the calling stack.
Each initialization function multiplies the data rate by Y, and that is
passed to the next initialization function in the chain. Functions may
assemble frames into some larger packet, or disassemble packets into frames.
Given the chain of functions, the exact output data rate for a
particular input data rate can be determined, and remains constant after
initialization time. This can be used to choose a modem rate for an
arbitrary codec rate and transformation chaiin.
Sloppy concatenation of too many frame-size-transforming functions will
result in unacceptable delay.
The tear-down functions deallocate all memory resources that were
allocated by the initialization functions.
For efficiency in small-memory environments, transformation functions
are expected to refrain from allocating stack data.
For shared-memory efficiency, nothing in the system should define any
BSS data. Pre-defined data expected to be const so that it is placed in
text space.
Thanks
Bruce
On 10/23/2012 12:08 AM, Kristoff Bonne wrote:
> Hi all,
>
>
>
> One of the elements needed for implementation of the the 2400 bps modem
> is something called "interleaving".
>
> As this element is just "bit-processing" which does not really need
> knowledge of FEC, DSP, voice-encoding or the other "low-level" stuff;
> this might be an interesting project to develop by itself.
>
> If somebody is interested in this, do let me know; either via the list
> of offlist. If you always wanted to get your name in the official
> documentation as cool as an open source voice codec; this is your
> chance. :-)
>
>
> What is this about:
> * Interleaving is a simple but genious trick used to beat burst-errors.
> Burst-errors is a senario where interference of a radio-signal takes
> that long it modfies not one bit, but multiple bits after other. This is
> an issue for two reasons:
> - some FEC systems operate on a relative small group of bits or a number
> of bits located after eachother.
> - certain bits in a voice stream are more important then others. The
> audiable effect of having certain bits modified is much larger then
> having some other bits changed. It is therefor important that not all
> "important" bits are wiped out by one single bursterror.
>
> * Interleaving is as simple as effective: it simply changes the order of
> the bits transmitted so that bits that are important or "related" are
> not transmitted after eachother. To do this,
> - the bits order it changed before transmitting
> - the stream is transmitted
> - on the receiving end, the order of the bits is corrected again.
>
>
>
> So, this is the senario; as taking from the 2400 c2_gmsk spec:
>> 2/ for the 1400 bps voice codec:
> (...)
>> 2b/ For a timeslot WITH sync/type-of-frame pattern:
>> - 24 bits sync/type-of-frame
>> - 56 bits codec2 voice
>> - 16 bits FEC
>>
>> In this senario,
>> - once golay(24,12,8) is applied, with the ability to protect 12 bits
>> - in addition, one hamming(8,4,4) is applied, with the ability to
>> protect 4 bits.
>>
>> Firstly, the golay(24,12,8) is applied to the following bits:
>> - all 4 voiced bits
>> - the 8 energy/wo bits that apply to the first two codec2 frames of
>> the (4 frame) codec2 timeslot
>>
>> For the 4 remaing FEC bits (the hamming(8,4,4) block), I would like to
>> propose this:
>> The hamming(8,4,4) is applied NOT 4 of the other eight energy+wo bits
>> (for the 3th and 4th frame), but 4 of the MSBs of the LSPs.
> Also important to know:
>
> > * A codec2 frame is based on a 40 ms timeslot, containing information
> about four 10 ms frames. It has the following structure:
> >1/ For the 1400 bps voice codec
> > - 1 "voiced" bit for frame 0
> > - 1 "voiced" bit for frame 1
> > - 8 "energy or WoE" bits for frames 0 and 1
> > - 1 "voiced" bit for frame 2
> > - 1 "voiced" bit for frame 3
> > - 8 "energy or WoE" bits for frames 2 and 3
> > - 36 "LSP" bits for frames 0 up to 3
> > Total: 56 bits
> > The 36 LSP bits represent 10 values, using between 2 and 4 bits for
> every values.
>
>
> And:
>
> > Not all information in the codec2 voice frame is equaly important.
> Corrupting certain bits produces more audiable error then other bits.
> The importance of the different
> > groups of bits is as follows (in descending order):
> > - voicing bits
> > - energy+Wo bits
> > - MSB part of the LSPs
> > - remaining part of the LSPs
>
>
>
> What is needed:
> A interleaving matrix which modifies the order of the bits as stored in
> the 72 bits of the to-be transmitted frame, into an order less
> vulnerable for burst errors:
>
> The rules are as follows:
> - bits with a high importance (like the voice-bits and energy+wo bits)
> should NOT be located close other bits with a high priority.
>
> - bits that are related should also not be located close to eachother.
> "related" bits are all bits that are part of the same FEC block: both
> the databits and the error-correction bits of the FEC block.
> In this case, there are two FEC blocks:
> . one 24 bit "golay(12,24)" block: containting the 4 voice bits, the 8
> "energy.wo" bits of the first frame + the 12 error-correction bits for
> that block
> . one 8 "hamming(4;8)" block: containing 4 of the MSBbits of the LSPs +
> 4 error-correction bit for that block
>
>
> Who takes up the challence to give this a try.
>
> One way to do this is write an application that compaires possible
> interleaving-matrices giving them all a score how well they based on the
> requirement (it they end up with some of the important bits located next
> to eachother, it should have a bad score).
> This would allow us to compair different matrices.
>
>
> Anybody interested?
>
> Feel free to reply via the list or offlist.
>
>
>
> 73
> Kristoff - ON1ARF
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Freetel-codec2 mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
