|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:58||Date Closed:||2012-05-09 14:18:19|
|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.