[Home]

Summary:ASTERISK-11567: Transcoded G.722 calls unintelligible
Reporter:Rick Ross (rickross)Labels:
Date Opened:2008-03-03 20:53:06.000-0600Date Closed:2008-03-06 18:43:39.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Codecs/codec_g722
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) recorded-name-722.wav
( 1) recorded-name-wav.wav
Description:Ever since moving from 1.4.13 to 1.6.0b4 my users have been unable to use G.722 successfully. The transcoding seems fine from other formats like ulaw/gsm into G.722, but the other direction is almost completely garbled and makes it sound like the speaker is under water. It is barely intelligible (with some good guesswork.)

I'd be happy to give someone a call to demonstrate, if that would help. For now we're simply disabling G.722 completely (a pity, since it sounds so good when it works.) We had been using a backported G.722 under 1.4.x for many months, so we know it can work. SOmething seems to have changed in the 1.6 beta.

****** ADDITIONAL INFORMATION ******

This person seems to be having a very similar issue:
http://www.spinics.net/lists/asterisk/msg84469.html
Comments:By: Paul Milazzo (milazzo) 2008-03-04 06:25:38.000-0600

In attempting to isolate the problem, I created two extensions that record to files; one records and plays back in g722, the other in wav format:

       5081 => {
           Answer();
           Playback(en/priv-recordintro);
           Playback(en/then-press-pound);
           Wait(1);
           Record(/tmp/recorded-name-g722.g722);
           Wait(1);
           Playback(en/beep);
           Playback(/tmp/recorded-name-g722);
           Playback(en/beep);
           Hangup();
       };
       5085 => {
           Answer();
           Playback(en/priv-recordintro);
           Playback(en/then-press-pound);
           Wait(1);
           Record(/tmp/recorded-name-wav.wav);
           Wait(1);
           Playback(en/beep);
           Playback(/tmp/recorded-name-wav);
           Playback(en/beep);
           Hangup();
       };

When I call them from a Polycom 650 in g722 format, the g722 recording sounds fine but the wav recording is terribly distorted. If I use "file convert" in Asterisk to convert the g722 recording to wav format, the resulting .wav file also sounds fine. I have attached the two sample files.

- Paul
By: snuffy (snuffy) 2008-03-04 22:23:40.000-0600

milazzo, russell applied the fix to trunk/1.4
Please retest with svn of 1.6

*** russell, asterisk, branch-1.4, r105932 ***
Fix a bug that I just noticed in the RTP code.  The calculation for setting the len field in an ast_frame of audio was wrong when G.722 is in use.  The len field represents the number of ms of audio that the frame contains.  It would have set the value to be twice what it should be.

*** russell, asterisk, trunk, r105933 ***
By: Russell Bryant (russell) 2008-03-04 23:03:59.000-0600

That fix was probably unrelated.  It was just something I noticed while looking around.  I haven't had a chance to test for this issue yet, but I'm hoping to do it tomorrow.  Definitely this week, though ...
By: Paul Milazzo (milazzo) 2008-03-05 06:38:57.000-0600

I retested with trunk r105983, but the problem persists; sorry.
By: Digium Subversion (svnbot) 2008-03-06 16:12:13.000-0600

Repository: asterisk
Revision: 106441

A   team/russell/g722-sillyness/

------------------------------------------------------------------------
r106441 | russell | 2008-03-06 16:12:13 -0600 (Thu, 06 Mar 2008) | 3 lines

create a branch for some g722 bug fixes
(issue ASTERISK-11567)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=106441
By: Digium Subversion (svnbot) 2008-03-06 16:24:43.000-0600

Repository: asterisk
Revision: 106494

U   team/russell/g722-sillyness/formats/format_pcm.c
U   team/russell/g722-sillyness/main/file.c

------------------------------------------------------------------------
r106494 | russell | 2008-03-06 16:24:40 -0600 (Thu, 06 Mar 2008) | 11 lines

Fix up some places where numbers of samples were improperly generated and interpreted
for G.722.  This explains why recording to wav and then playing it back was broken,
but converting g.722 to wav via the "file convert" CLI command worked.  That was because
the frames coming in from RTP had the correct numbers of samples in the frames.
However, reading from the g722 file stream had the incorrect number of samples.  I
fixed this, but that unfortunately means that both methods are now equally broken.

Next, figure out where playing back a non-g722 format to a g722 phone is broken.

(issue ASTERISK-11567)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=106494
By: Digium Subversion (svnbot) 2008-03-06 17:21:41.000-0600

Repository: asterisk
Revision: 106496

U   team/russell/g722-sillyness/codecs/codec_g722.c
U   team/russell/g722-sillyness/main/rtp.c

------------------------------------------------------------------------
r106496 | russell | 2008-03-06 17:21:35 -0600 (Thu, 06 Mar 2008) | 4 lines

Fix a couple more g722 sample issues ...

(issue ASTERISK-11567)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=106496
By: Digium Subversion (svnbot) 2008-03-06 18:02:33.000-0600

Repository: asterisk
Revision: 106499

U   team/russell/g722-sillyness/codecs/codec_g722.c

------------------------------------------------------------------------
r106499 | russell | 2008-03-06 18:02:32 -0600 (Thu, 06 Mar 2008) | 6 lines

Fix another bit of sillyness regarding g722 samples.  g722_decode() expects the
samples parameter to be the number of samples / 2 ... stupid incorrect specs that
people follow anyway ...

(issue ASTERISK-11567)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=106499
By: Digium Subversion (svnbot) 2008-03-06 18:21:05.000-0600

Repository: asterisk
Revision: 106501

U   trunk/codecs/codec_g722.c
U   trunk/formats/format_pcm.c
U   trunk/main/file.c
U   trunk/main/rtp.c

------------------------------------------------------------------------
r106501 | russell | 2008-03-06 18:21:04 -0600 (Thu, 06 Mar 2008) | 28 lines

Merge changes from team/russell/g722-sillyness ...

Fix a number of other places where the number of samples in a G722 frame was
not properly handled because of various reasons.

main/rtp.c:
- When a G722 frame is read from the smoother, the number of samples in the
  frame must be divided by 2 before being sent out over the network.  Even
  though G722 is 16 kHz, an error in some previous spec has made it so that
  we have to list the number of samples such as if it was 8 kHz.

main/file.c:
- When scheduling the next time to expect a frame, take into account that the
  format of the file we're reading from may not be 8 kHz.

codecs/codec_g722.c:
- When converting from G722 to slinear, g722_decode() expects its samples
  parameter to be in the silly (real samples / 2) format.  Make it so.
- When converting from slinear to G722, properly set the number of samples in
  the frame to be the number of bytes of output * 2.

formats/format_pcm.c:
- This format module handles G722, among a number of other formats.  However,
  the read() and seek() functions did not account for the fact that G722 has
  2 samples per byte.

(closes issue ASTERISK-11567, reported by rickross, patched by me)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=106501
By: Digium Subversion (svnbot) 2008-03-06 18:21:59.000-0600

Repository: asterisk
Revision: 106502

_U  branches/1.6.0/
U   branches/1.6.0/codecs/codec_g722.c
U   branches/1.6.0/formats/format_pcm.c
U   branches/1.6.0/main/file.c
U   branches/1.6.0/main/rtp.c

------------------------------------------------------------------------
r106502 | russell | 2008-03-06 18:21:59 -0600 (Thu, 06 Mar 2008) | 36 lines

Merged revisions 106501 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
r106501 | russell | 2008-03-06 18:24:58 -0600 (Thu, 06 Mar 2008) | 28 lines

Merge changes from team/russell/g722-sillyness ...

Fix a number of other places where the number of samples in a G722 frame was
not properly handled because of various reasons.

main/rtp.c:
- When a G722 frame is read from the smoother, the number of samples in the
  frame must be divided by 2 before being sent out over the network.  Even
  though G722 is 16 kHz, an error in some previous spec has made it so that
  we have to list the number of samples such as if it was 8 kHz.

main/file.c:
- When scheduling the next time to expect a frame, take into account that the
  format of the file we're reading from may not be 8 kHz.

codecs/codec_g722.c:
- When converting from G722 to slinear, g722_decode() expects its samples
  parameter to be in the silly (real samples / 2) format.  Make it so.
- When converting from slinear to G722, properly set the number of samples in
  the frame to be the number of bytes of output * 2.

formats/format_pcm.c:
- This format module handles G722, among a number of other formats.  However,
  the read() and seek() functions did not account for the fact that G722 has
  2 samples per byte.

(closes issue ASTERISK-11567, reported by rickross, patched by me)

........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=106502
By: Digium Subversion (svnbot) 2008-03-06 18:43:39.000-0600

Repository: asterisk
Revision: 106504

_U  team/file/bridging/
U   team/file/bridging/codecs/codec_g722.c
U   team/file/bridging/formats/format_pcm.c
U   team/file/bridging/main/file.c
U   team/file/bridging/main/rtp.c

------------------------------------------------------------------------
r106504 | file | 2008-03-06 18:43:38 -0600 (Thu, 06 Mar 2008) | 36 lines

Merged revisions 106501 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
r106501 | russell | 2008-03-06 20:24:58 -0400 (Thu, 06 Mar 2008) | 28 lines

Merge changes from team/russell/g722-sillyness ...

Fix a number of other places where the number of samples in a G722 frame was
not properly handled because of various reasons.

main/rtp.c:
- When a G722 frame is read from the smoother, the number of samples in the
  frame must be divided by 2 before being sent out over the network.  Even
  though G722 is 16 kHz, an error in some previous spec has made it so that
  we have to list the number of samples such as if it was 8 kHz.

main/file.c:
- When scheduling the next time to expect a frame, take into account that the
  format of the file we're reading from may not be 8 kHz.

codecs/codec_g722.c:
- When converting from G722 to slinear, g722_decode() expects its samples
  parameter to be in the silly (real samples / 2) format.  Make it so.
- When converting from slinear to G722, properly set the number of samples in
  the frame to be the number of bytes of output * 2.

formats/format_pcm.c:
- This format module handles G722, among a number of other formats.  However,
  the read() and seek() functions did not account for the fact that G722 has
  2 samples per byte.

(closes issue ASTERISK-11567, reported by rickross, patched by me)

........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=106504