Audio breaking while in conversation

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Call from one flex client to another
2. Call is established
3. Both sides audio can be heard, but on one side the audio stream plays like 
it is muting every half second. I am using codec ulaw.

What is the expected output? What do you see instead?
Continous audio on both side.

A similar problem was posted here:
http://code.google.com/p/red5phone/issues/detail?id=32&sort=-id&start=100

What version of the product are you using? On what operating system?
Red 5 - 0.9.1
Red5 Phone - r47 flex client

Please provide any additional information below.
OS - Windows XP
AsterixWin32 PBX

Any help is appreciated.

Original issue reported on code.google.com by harikuma...@gmail.com on 29 Jul 2011 at 6:13

[GoogleCodeExporter]

I finally got r53 working with RED5 0.9.1.
Sadly the choppy audio problem persists.

Original comment by harikuma...@gmail.com on 30 Jul 2011 at 2:20

[GoogleCodeExporter]

Well, to update the status, the choppy audio problem on one end was caused by 
the lack of a jitter buffer at the red5phone receiving end. I could capture the 
packets moving to and from asterisk using wireshark and played audio from the 
captured packets. The audio plays fine with jitter buffer set at 50ms. When I 
try and decode the packets with a lower value like 40ms or 30ms the output 
starts getting jitters. 

I am now working on an adaptive jitter buffer implementation. Also could be 
good if we could get rid of the nellymoser decoding and encoding which is now 
possible if we use Flash Player 11 (only beta version is available now) as I 
understand it can handle ulaw directly. Those could be future enhancements.

Original comment by harikuma...@gmail.com on 5 Aug 2011 at 5:25

[GoogleCodeExporter]

Hello!
Any luck on this? 
We can donate some sum of money to help

Original comment by kay...@gmail.com on 15 Aug 2011 at 4:02

[GoogleCodeExporter]

Hi, I am nearly finishing the jitter buffer implementation and the audio sounds 
much better. No more choppiness, but some really negligible background noise. 
Trying to fix that issue.

Will start with the Speex version and try and get rid of the Nellymoser 
encoding decoding soon. 

Original comment by harikuma...@gmail.com on 15 Aug 2011 at 9:07

[GoogleCodeExporter]

Am also very interested in what you are trying to archive, coz i noticed the 
sound quality of tringme web-phone client is very good and they use speex codec.
I am willing to also donate some money on this good work.

Original comment by katura2...@gmail.com on 21 Aug 2011 at 12:11

[GoogleCodeExporter]

I came across this opensource project ie http://bigbluebutton.org/ that managed 
to implement speex and on testing gives a very good sound quality. 

https://github.com/bigbluebutton/bigbluebutton/tree/master/bbb-voice/src/main/ja
va/org/red5/app/sip/codecs

Hope this helps.

Original comment by katura2...@gmail.com on 21 Aug 2011 at 12:53

[GoogleCodeExporter]

The breaking sound in r54 is caused by the incorrect timestamp of RTMP messages 
when generate RTMP message from RTP.

Review the source code of r54, RTPStreamReceiver.java in package 
org.red5.server.webapp.sip:

----------------
while ( running ) {
  try {
      rtp_socket.receive( rtpPacket );
      frameCounter++;

      if ( running ) {

          byte[] packetBuffer = rtpPacket.getPacket();
          int offset = rtpPacket.getHeaderLength();
          int length = rtpPacket.getPayloadLength();
          int payloadType = rtpPacket.getPayloadType();

          if(payloadType < 20)
          {
             System.arraycopy(packetBuffer, offset, codedBuffer, 0, sipCodec.getIncomingEncodedFrameSize());

             timeStamp = (int)(System.currentTimeMillis() - start);
             rtmpUser.pushAudio(codedBuffer, timeStamp, 130);
          }
      }
  }
  catch ( java.io.InterruptedIOException e ) {
  }
}

Take a look to RTMP Specification (Doc: rtmp_specification_1.0.pdf):

Timestamps MUST be monotonically increasing, and SHOULD be linear in time, to 
allow applications to handle synchronization, bandwidth measurement, jitter 
detection, and flow control.

In above source code, the value of timeStamp is not linear because RTP is 
transported in UDP and variable timeStamp is calculated by RTP receving time. 
The non-linear timestamp will lead the flash client can't organize the audio 
data correctly.

To solve this issue, just change one line of above code.

The following line:

timeStamp = (int)(System.currentTimeMillis() - start);

to:

timeStamp += sipCodec.getIncomingPacketization(); 

After re-compile, you should find the sound more better than before. w/o jitter.

Original comment by yilin...@gmail.com on 1 Jun 2012 at 6:33