[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[HLL] Re: Frames again...

Status: RO
Content-Length: 3819
Lines: 85

Maybe you have already received the following message.
But i never got it back from the list myself,
even though i send it about 6 hours ago. So i send it again...



Hi Rob,

> Looks like you're into it!

I really like this kind of stuff...

> > So it mainly interprets the 4 mode-bits and splits frames accordingly.
> > Our frames might be structures as described in the "quick and dirty"
> > proposal earlier. Fields should be in this sequence:
> > *   4 Bits coding operation-mode "mode-bits"
> > * 260 Bits coding used as "G-channel" (13000 Baud @ 20mSec/Frame)
> > *   8 Bits coding used as "X-channel" (  400 Baud @ 20mSec/Frame)
> > This makes up a minimum frame of 34 bytes.
> > If frames are longer, any extra bytes belong to the "X-channel".

> Doesn't doing it this way mean that we can't switch to a slower codec?  
> (I'd love to have a mode that does (shitty) voice over 9600). More generally
> said: should the speed of the GSM codec be hardcoded in the lowest layers of
> the protocol?

Yes - in the current form it would be hard to change the number of codec-bits.
Until now our "supported minimum" was 144-link with gsm-full-rate-compression.
This reflects in the definition above.

To escape such problems, lets make these additional assumptions:
* There will always be "G-" and "X-channel", but the "split-point"
  is variable. Before using a combined audio/data-mode (modes 4,5),
  this split-point is negotiated implicit by codec-selection.
  [This selection uses only modes 2,3 to exchange messages.]
  [Minimum implementation will only support gsm-full-rate/260_bits]
  {It is sufficient if software supports splitting on byte-boundaries}
* Frame-rate should be the same as codec block-rate (20mSec/gsm).
  Frame-length should be selected to nearly fill up avaiable bandwidth.
  {Crypto would benefit if we limit block-length to even byte-counts.}
  {This makes it possible to operate in 16-bit-cfb, the best/fastest}
  {mode we can use when operating with minimum-block-size of 34-bytes}
  While on packet-switching-networks the len of individual frames may be
  different, it should remain fixed for modems. Given the rules above,
  there should not be a need to change frame-len with fixed baud-rate and
  codec-selection, because the number of bytes/line per codec-block-time is
  fixed. {This assumption is needed for frame-sync on async-lines by level 0}

With these additions, it should be possible to operate
with variable codecs and line-speeds.

Block-size for different codecs/line-speeds would be:
* Calculate the number of bytes on the line per codec-frame
* Leave about 3% (min 1 byte) of those bytes unused (speed variations)
* One byte is used as sync-byte and not avaiable for data
* The remaining bytes are avaiable for Level-1 and referred as "block size"

To reduce overhead with very short blocks at very low rates,
(i.e. gsm-halfrate/<14400), you might combine 2 of those "very short"
130-bit gsm-half-rate-blocks into one 260-bit chunk.
Then you would transmit frames at _half_ the codec-rate
(giving you additional 20mSec audio-delay), but no additional overhead
- - so you can overate this "standard" with gsm-half-rate on a 7200 link !
The same thing is possible with gsm-full-rate algorithm when you reduce
sampling-rate by 50%. Gives you about 1700_Hz audio-bandwidth...
If you use 9600 instead of 7200 even 2300_Hz ;-)


Version: 2.6.3i
Charset: latin1