Forums

G.711 implementation

Started by kostbill May 8, 2007
Hello.

I have read the G.711 spec from ITU and I have seen some implementations
written in C.

There is something I don't understand because I cannot understand it from
the spec and the different implementations I have seen produce different
results!

So, my question is in the bit ordering and in the bit inversing.

Example:

520 (dec) = 1000001000 -> 0 0 0 1 0 0 0 0 0 1 0 0 0
(sign bit first)--------> _ _ _ _ _ _ _ _ _ _ _ _ _

that gives 0 (sign), 101 (001 gives 101 from the spec), 0000 (next four
bits) -> 01010000 and that gives what ????????

So, bits are counting from left or from right? they are starting from zero
or 1? Am I going to OR with D5? 55 or 5D? If it is negative, what is the
difference?

I am confused.

Thank you very much.

_____________________________________
Do you know a company who employs DSP engineers?  
Is it already listed at http://dsprelated.com/employers.php ?
kostbill wrote:
> Hello. > > I have read the G.711 spec from ITU and I have seen some implementations > written in C. > > There is something I don't understand because I cannot understand it from > the spec and the different implementations I have seen produce different > results! > > So, my question is in the bit ordering and in the bit inversing. > > Example: > > 520 (dec) = 1000001000 -> 0 0 0 1 0 0 0 0 0 1 0 0 0 > (sign bit first)--------> _ _ _ _ _ _ _ _ _ _ _ _ _ > > that gives 0 (sign), 101 (001 gives 101 from the spec), 0000 (next four > bits) -> 01010000 and that gives what ???????? > > So, bits are counting from left or from right? they are starting from zero > or 1? Am I going to OR with D5? 55 or 5D? If it is negative, what is the > difference? > > I am confused.
Once the 13-bit sample is encoded to A-law, the 8-bit result is XOR'd with 0x55. IIRC, mu-law leaves the xor step off. You can look at G.711 as a poor-man's floating point. It has a sign bit, a three-bit exponent, and a 4-bit mantissa. Back in the old days when single-chip fixed-point DSPs were first introduced (circa 1985), ADI and TI both had app notes about encoding and decoding mu-law and A-law. Ahh... here it is. Look on this page for PCM.ZIP: http://www.analog.com/processors/adsp/technicalLibrary/codeExamples/applicationsHandbook.html The code is found in the book "ADSP-2100 Family Digital Signal Processing Applications" (ISBN 0-13-212978-7) and it's written in ADSP2100 assembly language. Luckily, it's not very difficult to read. HTH. -- Jim Thomas Principal Applications Engineer Bittware, Inc jthomas@bittware.com http://www.bittware.com (603) 226-0404 x536 Roses are #FF0000, violets are #0000FF, all my base are belong to you.
On May 8, 9:48 am, Jim Thomas <jtho...@bittware.com> wrote:
> kostbill wrote: > > Hello. > > > I have read the G.711 spec from ITU and I have seen some implementations > > written in C. > > > There is something I don't understand because I cannot understand it from > > the spec and the different implementations I have seen produce different > > results! > > > So, my question is in the bit ordering and in the bit inversing. > > > Example: > > > 520 (dec) = 1000001000 -> 0 0 0 1 0 0 0 0 0 1 0 0 0 > > (sign bit first)--------> _ _ _ _ _ _ _ _ _ _ _ _ _ > > > that gives 0 (sign), 101 (001 gives 101 from the spec), 0000 (next four > > bits) -> 01010000 and that gives what ???????? > > > So, bits are counting from left or from right? they are starting from zero > > or 1? Am I going to OR with D5? 55 or 5D? If it is negative, what is the > > difference? > > > I am confused. > > Once the 13-bit sample is encoded to A-law, the 8-bit result is XOR'd > with 0x55. IIRC, mu-law leaves the xor step off. You can look at G.711 > as a poor-man's floating point. It has a sign bit, a three-bit > exponent, and a 4-bit mantissa. > > Back in the old days when single-chip fixed-point DSPs were first > introduced (circa 1985), ADI and TI both had app notes about encoding > and decoding mu-law and A-law. > > Ahh... here it is. Look on this page for PCM.ZIP:http://www.analog.com/processors/adsp/technicalLibrary/codeExamples/a... > The code is found in the book "ADSP-2100 Family Digital Signal > Processing Applications" (ISBN 0-13-212978-7) and it's written in > ADSP2100 assembly language. Luckily, it's not very difficult to read. > > HTH. > > -- > Jim Thomas Principal Applications Engineer Bittware, Inc > jtho...@bittware.com http://www.bittware.com (603) 226-0404 x536 > Roses are #FF0000, violets are #0000FF, all my base are belong to you.- Hide quoted text - > > - Show quoted text -
In mu-law, the 8 bit value gets xored with 0xFF. So the values near zero are 0xFF and 0x7F - the reason behind this lies with the line coding. It is easier to stay synched with signals that are "ones" rich as opposed to "zeros" rich. Thus you dont want quiet lines to be almost all zereos. Clay
Gentlemen,

Thank you very much for your immediate responses.

I am sorry but I will ask more questions now :).

(1) I understand that you say to XOR with 0x55, but as my first question,
the bit counting (bit zero) is from the right or left? Also, the counting
starts from "bit one" or "bit zero"? There are some codes in the internet
where they XOR with 0xD5, and I think that the sun code, XORs with 55 if
the number is positive and with 0xD5 if the number is negative (for
a-law).

(2) If I understand correctly, you said that the AD DSP is not performing
the XOR yes? Then I guess that this is not going to be a problem if I do
not perform it either, I mean, OK, when G.711 was out in the 60s, there
was a problem with many zeros in the row, but now, since this is an VoIP
application, there is not going to be an error or something bad if I do
not XOR the result, do you agree with me?

My regards,
Bill.


>On May 8, 9:48 am, Jim Thomas <jtho...@bittware.com> wrote: >> kostbill wrote: >> > Hello. >> >> > I have read the G.711 spec from ITU and I have seen some
implementations
>> > written in C. >> >> > There is something I don't understand because I cannot understand it
from
>> > the spec and the different implementations I have seen produce
different
>> > results! >> >> > So, my question is in the bit ordering and in the bit inversing. >> >> > Example: >> >> > 520 (dec) = 1000001000 -> 0 0 0 1 0 0 0 0 0 1 0 0 0 >> > (sign bit first)--------> _ _ _ _ _ _ _ _ _ _ _ _ _ >> >> > that gives 0 (sign), 101 (001 gives 101 from the spec), 0000 (next
four
>> > bits) -> 01010000 and that gives what ???????? >> >> > So, bits are counting from left or from right? they are starting from
zero
>> > or 1? Am I going to OR with D5? 55 or 5D? If it is negative, what is
the
>> > difference? >> >> > I am confused. >> >> Once the 13-bit sample is encoded to A-law, the 8-bit result is XOR'd >> with 0x55. IIRC, mu-law leaves the xor step off. You can look at
G.711
>> as a poor-man's floating point. It has a sign bit, a three-bit >> exponent, and a 4-bit mantissa. >> >> Back in the old days when single-chip fixed-point DSPs were first >> introduced (circa 1985), ADI and TI both had app notes about encoding >> and decoding mu-law and A-law. >> >> Ahh... here it is. Look on this page for
PCM.ZIP:http://www.analog.com/processors/adsp/technicalLibrary/codeExamples/a...
>> The code is found in the book "ADSP-2100 Family Digital Signal >> Processing Applications" (ISBN 0-13-212978-7) and it's written in >> ADSP2100 assembly language. Luckily, it's not very difficult to read. >> >> HTH. >> >> -- >> Jim Thomas Principal Applications Engineer Bittware, Inc >> jtho...@bittware.com http://www.bittware.com (603) 226-0404 x536 >> Roses are #FF0000, violets are #0000FF, all my base are belong to you.-
Hide quoted text -
>> >> - Show quoted text - > > >In mu-law, the 8 bit value gets xored with 0xFF. So the values near >zero are 0xFF and 0x7F - the reason behind this lies with the line >coding. It is easier to stay synched with signals that are "ones" rich >as opposed to "zeros" rich. Thus you dont want quiet lines to be >almost all zereos. > >Clay > > > >
_____________________________________ Do you know a company who employs DSP engineers? Is it already listed at http://dsprelated.com/employers.php ?
kostbill wrote:
> Gentlemen, > > Thank you very much for your immediate responses. > > I am sorry but I will ask more questions now :). > > (1) I understand that you say to XOR with 0x55, but as my first question, > the bit counting (bit zero) is from the right or left? Also, the counting > starts from "bit one" or "bit zero"?
I did not address this because I did not understand the question. Which word are you talking about (unencoded or encoded?).
> There are some codes in the internet > where they XOR with 0xD5, and I think that the sun code, XORs with 55 if > the number is positive and with 0xD5 if the number is negative (for > a-law).
My guess is that they combined the logic to set the sign bit with the XOR logic.
> > (2) If I understand correctly, you said that the AD DSP is not performing > the XOR yes?
I don't /think/ I said that. I said that IIRC (if I recall correctly) mu-law did not do an XOR. Clay pointed out that mu-law xor's with 0xff.
> Then I guess that this is not going to be a problem if I do > not perform it either, I mean, OK, when G.711 was out in the 60s, there > was a problem with many zeros in the row, but now, since this is an VoIP > application, there is not going to be an error or something bad if I do > not XOR the result, do you agree with me?
It would make documenting your system a lot easier if you stick to G.711 rather than skipping the XOR. Then you could just call out the spec rather than documenting caveats to it. Sticking to the spec would improve the chances of making your system interoperable. But as long as you have control over both the encoder and the decoder, you are free to skip the xor or even invent your own compression scheme. -- Jim Thomas Principal Applications Engineer Bittware, Inc jthomas@bittware.com http://www.bittware.com (603) 226-0404 x536 Failure is always an option
On May 9, 2:16 am, "kostbill" <vak...@intracomdefense.com> wrote:
> Gentlemen, > > Thank you very much for your immediate responses. > > I am sorry but I will ask more questions now :). > > (1) I understand that you say to XOR with 0x55, but as my first question, > the bit counting (bit zero) is from the right or left? Also, the counting > starts from "bit one" or "bit zero"? There are some codes in the internet > where they XOR with 0xD5, and I think that the sun code, XORs with 55 if > the number is positive and with 0xD5 if the number is negative (for > a-law). > > (2) If I understand correctly, you said that the AD DSP is not performing > the XOR yes? Then I guess that this is not going to be a problem if I do > not perform it either, I mean, OK, when G.711 was out in the 60s, there > was a problem with many zeros in the row, but now, since this is an VoIP > application, there is not going to be an error or something bad if I do > not XOR the result, do you agree with me? > > My regards, > Bill. >
Hello Bill, You would be wise to heed Jim's advice. If you forget the xor and you send your data to a compliant G.711 codec, the audio will sound very loud and very distorted. Clay
>On May 9, 2:16 am, "kostbill" <vak...@intracomdefense.com> wrote: >> Gentlemen, >> >> Thank you very much for your immediate responses. >> >> I am sorry but I will ask more questions now :). >> >> (1) I understand that you say to XOR with 0x55, but as my first
question,
>> the bit counting (bit zero) is from the right or left? Also, the
counting
>> starts from "bit one" or "bit zero"? There are some codes in the
internet
>> where they XOR with 0xD5, and I think that the sun code, XORs with 55
if
>> the number is positive and with 0xD5 if the number is negative (for >> a-law). >> >> (2) If I understand correctly, you said that the AD DSP is not
performing
>> the XOR yes? Then I guess that this is not going to be a problem if I
do
>> not perform it either, I mean, OK, when G.711 was out in the 60s,
there
>> was a problem with many zeros in the row, but now, since this is an
VoIP
>> application, there is not going to be an error or something bad if I
do
>> not XOR the result, do you agree with me? >> >> My regards, >> Bill. >> > >Hello Bill, > >You would be wise to heed Jim's advice. If you forget the xor and you >send your data to a compliant G.711 codec, the audio will sound very >loud and very distorted. > >Clay > > >
Hello. Thanks again for the help you provide. Clay, of course I will not perform the XOR in the decoder either. Anyway, you are right about the documentation. I would like to ask you something a bit different. Of course you know the C implementation of G.711, I think there are a couple of bugs there. I don't know if you have seen it and I don't know what to assume but I would bet that there are bugs. Also, the TI code that Jim told me to download has a small bug. Can this be true? I mean that these companies cannot make such mistakes yes? Would you be interesting in showing you the bugs I found in both these implementations? It could help me a lot. Thank you very much. _____________________________________ Do you know a company who employs DSP engineers? Is it already listed at http://dsprelated.com/employers.php ?
I am sorry, when I said: "Of course you know the C implementation of G.711"
I had the Sun C code in mind :).


_____________________________________
Do you know a company who employs DSP engineers?  
Is it already listed at http://dsprelated.com/employers.php ?
On May 10, 2:31 am, "kostbill" <vak...@intracomdefense.com> wrote:
> >On May 9, 2:16 am, "kostbill" <vak...@intracomdefense.com> wrote: > >> Gentlemen, > > >> Thank you very much for your immediate responses. > > >> I am sorry but I will ask more questions now :). > > >> (1) I understand that you say to XOR with 0x55, but as my first > question, > >> the bit counting (bit zero) is from the right or left? Also, the > counting > >> starts from "bit one" or "bit zero"? There are some codes in the > internet > >> where they XOR with 0xD5, and I think that the sun code, XORs with 55 > if > >> the number is positive and with 0xD5 if the number is negative (for > >> a-law). > > >> (2) If I understand correctly, you said that the AD DSP is not > performing > >> the XOR yes? Then I guess that this is not going to be a problem if I > do > >> not perform it either, I mean, OK, when G.711 was out in the 60s, > there > >> was a problem with many zeros in the row, but now, since this is an > VoIP > >> application, there is not going to be an error or something bad if I > do > >> not XOR the result, do you agree with me? > > >> My regards, > >> Bill. > > >Hello Bill, > > >You would be wise to heed Jim's advice. If you forget the xor and you > >send your data to a compliant G.711 codec, the audio will sound very > >loud and very distorted. > > >Clay > > Hello. > > Thanks again for the help you provide. > > Clay, of course I will not perform the XOR in the decoder either. Anyway, > you are right about the documentation. > > I would like to ask you something a bit different. > > Of course you know the C implementation of G.711, I think there are a > couple of bugs there. I don't know if you have seen it and I don't know > what to assume but I would bet that there are bugs. > > Also, the TI code that Jim told me to download has a small bug. > > Can this be true? I mean that these companies cannot make such mistakes > yes? > > Would you be interesting in showing you the bugs I found in both these > implementations? It could help me a lot. > > Thank you very much. > > _____________________________________ > Do you know a company who employs DSP engineers? > Is it already listed athttp://dsprelated.com/employers.php?- Hide quoted text - > > - Show quoted text -
Hello Bill, I used a Motorola app note and wrote my own mu-law/A-Law coders and decoders. The appnote had tables of data so I was able to check the inputs and outputs. Of course the final test was when the code was used on actual E1 and T1 circuits connected to the public switched network. Clay
On May 10, 7:23 am, "kostbill" <vak...@intracomdefense.com> wrote:
> I am sorry, when I said: "Of course you know the C implementation of G.711" > I had the Sun C code in mind :). > > _____________________________________ > Do you know a company who employs DSP engineers? > Is it already listed athttp://dsprelated.com/employers.php?
Try looking here - it has c code: http://en.wikipedia.org/wiki/%CE%9C-law_algorithm