Summary:ASTERISK-19643: codec_dahdi: Block on frameout if the hardware has enough samples to complete a frame.
Reporter:Shaun Ruffell (sruffell)Labels:
Date Opened:2012-04-05 15:03:58Date Closed:2012-05-09 14:18:19
Versions: Frequency of
Environment:Attachments:( 0) 0001-codec_dahdi-Block-on-frameout-the-hardware-has-enoug.patch
Description: Given the following generic scenario:                                                                                                                                        
   RTP(g729) -> codec_dahdi -> RTP(ulaw) -> chan_dahdi -> phones                                                                                                                
   I received a report that if codec_dahdi was replaced with codec_g729 skipping                                                                                                
   audio was no longer observed on the phones on the far left. It appeared that                                                                                                
   there were bursts of audio that could cause frames to accumulate at the                                                                                                      
   ingress to chan_dahdi and potentially the jitter buffer was interfering.                                                                                                    
   Regardless, the below change, which makes codec_dahdi operate in a more                                                                                                      
   synchronous fashion, like codec_g729, made the problem go away for the user.                                                                                                
   As a side effect, use the file conversion tools from the Asterisk CLI now also                                                                                              
   The downside is that the thread responsible for transcoding the audio may be                                                                                                
   blocked for several milliseconds while it waits for the hardware transcoder to                                                                                              
   complete, but other threads in the system are free to do work and the overall                                                                                                
   load on the system remains low.                  
Comments:By: Shaun Ruffell (sruffell) 2012-04-05 15:22:21.294-0500

I opened this issue in order to post the patch for Sean Bright to try out.

By: Sean Bright (seanbright) 2012-04-13 09:42:50.142-0500

Deployed on 3 machines in production with no adverse affects reported.  These machines are only using decoders however.  Will roll out to hardware that uses both encoders and decoders and report back the results.

By: Shaun Ruffell (sruffell) 2012-04-16 13:16:02.277-0500

Thanks. I appreciate it.

By: Sean Bright (seanbright) 2012-04-18 09:11:21.193-0500

Deployed across all of our production PBXs and haven't experienced any problems.

By: Shaun Ruffell (sruffell) 2012-04-19 13:47:52.588-0500

Thanks for testing. I'll start the process of moving this onto the respective branches.