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

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 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 ?

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

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

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 ?

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

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.

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 ?