Uploaded image for project: 'FreeSWITCH'
  1. FreeSWITCH
  2. FS-3735

Choppy incoming audio to flash player using mod_rtmp

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Incomplete
    • Affects Version/s: 1.0.7
    • Fix Version/s: None
    • Component/s: Bounty
    • Security Level: public
    • Labels:
      None
    • Environment:
      Linux, Mac, Windows
    • CPU Architecture:
      x86
    • Kernel:
      Linux
    • uname:
      Linux version 2.6.32-71.el6.x86_64 (mockbuild@c6b6.centos.org)
    • Userland:
      GNU/Linux
    • lsb_release:
      Hide
      LSB Version:    :core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
      Distributor ID: CentOS
      Description:    CentOS Linux release 6.0 (Final)
      Release:        6.0
      Codename:       Final
      Show
      LSB Version:    :core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch Distributor ID: CentOS Description:    CentOS Linux release 6.0 (Final) Release:        6.0 Codename:       Final
    • Compiler:
      gcc
    • Compiler Version:
      gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC)
    • FreeSWITCH GIT Revision:
      FreeSWITCH Version 1.0.head (git-08b25a8 2011-11-09 10-29-42 -0600)
    • GIT Master Revision hash::
      yes
    • Target Version:

      Description

      We're having an issue with calls placed from Flash Player, where audio coming in to Flash Player from FS is getting very choppy. It appears that it happens mostly when listening to recorded audio like hold music, as when a call first connects, the IVR voice prompts usually sound ok, but as soon as the call is placed on hold and the hold music begins playing, and the audio becomes very choppy.

      One thing we have noticed is that during the times the incoming audio is choppy, we can see when capturing packets in Wireshark there seems to be a lot of extra network activity going on from FS to Flash. If we set the bufferTime on the incoming stream .1 (anything other than 0), we receive a steady stream of alternating "buffer empty" / "buffer full" events that correspond to the choppy audio. Additionally, the longer the duration of the call through Flex client, the higher the chance of media distortion becomes.

      We have VAD disabled, and have tried various tweaks to the mod_rtmp settings, none of which seemed to really make a difference:
      BUFFER-LEN to 50 , 100 , 25 , 200
      CHUNK SIZE to 128, 512, 1024, 2048 and 65536.

      On the flash side, the only setting that appeared to make any difference was setting the Microphone.silenceLevel higher than 0, but that only helped up to a point, as the higher the silence level got, the higher the more the audio would get distorted again.


      Note that this distortion in media is not observed when a call is placed through a VoIP phone.



      You can test the Flex app at: http://216.52.221.154/freeswitchlatest/
      - All clients connect to mod_rtmp on the default profile.
      - Fill in the details and press 'Call Button'.
      - The inbound leg is bridged to Outgoing leg with the details filled in the client.
      - FS Outbound Event Socket( Java ) is used to bridge the inbound and outbound legs.

      You can control the mic's silenceLevel property by changing the "silence=20" query param.

      Additional test phone #'s:
      919885098850 - VodaFone India
      18004339014 - Dell Help center
      18884521505 - TollFreeForwarding


      Looking to get this resolved and will pay any bounty required.




        Attachments

          Activity

            People

            • Assignee:
              anthm Anthony Minessale II
              Reporter:
              richrodecker Rich Rodecker
            • Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 4 days
                4d
                Remaining:
                Remaining Estimate - 4 days
                4d
                Logged:
                Time Spent - Not Specified
                Not Specified