Merged revisions 293970 via svnmerge from
authorShaun Ruffell <sruffell@digium.com>
Fri, 5 Nov 2010 00:08:09 +0000 (00:08 +0000)
committerShaun Ruffell <sruffell@digium.com>
Fri, 5 Nov 2010 00:08:09 +0000 (00:08 +0000)
commit178f3f1848cd4544322023e266637c013e83c806
tree9382e707314de5b18f190e9b94a7b1cca7e1d509
parentdcd6dae413cb94677601d1f43ca36cbb78da2514
Merged revisions 293970 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
  r293970 | sruffell | 2010-11-04 19:07:11 -0500 (Thu, 04 Nov 2010) | 32 lines

  Merged revisions 293969 via svnmerge from
  https://origsvn.digium.com/svn/asterisk/branches/1.6.2

  ................
    r293969 | sruffell | 2010-11-04 19:06:02 -0500 (Thu, 04 Nov 2010) | 25 lines

    Merged revisions 293968 via svnmerge from
    https://origsvn.digium.com/svn/asterisk/branches/1.4

    ........
      r293968 | sruffell | 2010-11-04 19:02:53 -0500 (Thu, 04 Nov 2010) | 17 lines

      codecs/codec_dahdi: Prevent "choppy" audio when receiving unexpected frame sizes.

      dahdi-linux 2.4.0 (specifically commit 9034) added the capability for
      the wctc4xxp to return more than a single packet of data in response to
      a read.  However, when decoding packets, codec_dahdi was still assuming
      that the default number of samples was in each read.

      In other words, each packet your provider sent you, regardless of size,
      would result in 20 ms of decoded data (30 ms if decoding G723). If your
      provider was sending 60 ms packets then codec_dahdi would end up
      stripping 40 ms of data from each transcoded frame resulting in "choppy"
      audio.

      This would only affect systems where G729 packets are arriving in sizes
      greater than 20ms or G723 packets arriving in sizes greater than 30ms.

      DAHDI-744.
    ........
  ................
................

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@293971 65c4cc65-6c06-0410-ace0-fbb531ad65f3
codecs/codec_dahdi.c