Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

Other people's experience with audio quality


Level 4

I was wondering what other people's experience has been with audio quality using P2P and/or Hub and spoke with LCCS.   We have a web based and an air based video chat client that we've been testing and so far our results are hit or miss (for both 2 way P2P and 3 way H&S).   We've been testing with hardware AEC, and without using headphones, with internal and external mics but I still get a lot of chopiness and it can be difficult to undertand each other even in a two way P2P call.

I know mileage will vary depending on how good the network connection is, but we're also using gmail's video chat right after as a control and the difference is night and day ( I know they have better audio codecs with variable bit rates and other fancy things etc etc.).  To be fair sometimes it sounds great even across country, but most times it's tough to understand one another.

Just wondering if everyone else was having similar problems or perhaps I'm missing something important here.  Any feedback is welcome.



0 Replies


Level 2

I have found that the best audio you are going to get is by requiring v10 of the player and setting up to use the Speex codec (set AudioPubliser.codec to SoundCodec.SPEEX). You still won't get builtin AEC since that is not yet supported by the flash player (many discussions/requests on this front...), but with either headphones or hardware AEC (I use a simple logitech usb speaker phone) the sound quality is pretty good. Without v10 and Speex, audio is unusable.

There are also audio controls you can play with (gain, encode quality, echo suppression, frames per packet, silence level) to balance bandwidth/quality. They can be found in the microphoneManager

Hope that helps - Chris


Not applicable

I also have had frustrating experiences with the Audio

quality with Adobe's services.   I haven't been paying attention to the threads here but now I am digging to find out whether they crippled the sound

service to have lesser sound quality in order to support scalability needs--- a while back, I thought I had stumbled upon a post where adobe said they are moving to a lesser mechanism instead of RTMFP but not sure this makes any sense (obviously i'm not the engineer implementing this but I know some technical stuff and need to educate myself a bit more)... at that time, I was too busy to investigate further.

I am testing a live site with Flash v10 and the appropriate LCCS audio Speex codec but have very diappointing audio quality and connection.  Sometimes it actually works great between users in US and even between US and Asia.  But most of the time, the connection and audio quality are so poor, people defect to skype.  I have to do more digging on this.  Would love to hear more about your frustrations--- oops never mind... I see your original post was in April 2009!  Don't know whether you'll see this message anytime soon 


Level 2

We are also running in a live site with mostly US to US participants although we have done early trials with clients in the UK as well. We also use the platform internally to host our team standup meetings and it works relatively well as long as everyone has reasonable bandwidth available to support all of the streams and everyone if wearing a headset to avoid echo...

We set up standard values for video and mic settings that we think work well for different connection speeds as well as expose both networking/bandwidth statistics as well as mic/video controls for making fine adjustments if an endpoint is experiencing quality issues. It all seems to work fairly well - if only we could get some sort of AEC in place then we could ditch the headphones and make it a whole lot better...

settings that we adjust on Camera include keyframeInterval and quality

settings that we adjust on Audio include gain, encodeQuality, framesPerPacket, silenceLevel, and echoSuppression

additionally we expose for monitoring network connection type, lccs connection type, available stream bandwidth, current video bandwidth, video frames dropped, audio stream bandwidth and audio frames dropped. These values are from the audio and video netStreamInfo objects as well as the connectSession streamManager and userManager (to get the connection type from a user's userDescriptor).

You should be able to adjust the various settings based on the user's connection type in order to optimize individual performance. I seem to remember that there was some sample that showed most of this, but I don't remember where that was...



Level 10

Hi ehb007,

  No need to ask if "they" did anything, we're right here for you to ask =). We're definitely still using RTMFP - in fact, we're scaling UP the amount of RTMFP traffic we can handle - we used to only support it on a few machines in our cloud (you have to specify protocol="rtmfp" in the AdobeHSAuthenticator to get it), but we're planning to open it up to all machines.

A few things :

1) Audio is *a LOT* better with RTMFP and Speex. Can you make sure that in your tests, your users are all on RTMFP connections? Some firewalls might prevent them from being able to. You can check UserDescriptor.isRTMFP to check (this wasn't in the ASDocs last build, we're fixing that).

2) Echo cancellation is still something the Flash Player needs to support for us. Please file your requests here : . I don't mean this as a "go bug someone else" brushoff, I'm actually in meetings with the Player folks this week, and the longer the thread from that page I can print out and bring to the meeting, the better off we'll all be =).

hope that helps,



Level 4

Jumping back a second to

44chughes's post and hoping Nigel might chime in.  I was just monitoring the netStreamInfo of my AudioPublisher and WebcamPublisher, by logging them every 30 seconds during a P2P video call.   I'm in my office so everything worked fine.   Then I put an ipfw restriction on my mac so it was bandwidth limited to 5KB/s in each direction.   This time I made the call with predictable results, it took longer to connect, video was dropping frames left and right and the audio was very choppy.

All that is fine and expected, but I was surprised to see that for the WebCamPublisher the currentBytesPerSecond=31698.880377136124, and for the AudioPublisher the currentBytesPerSecond=2617.9268903355032.   I figured I'd see them reported below the 5KB/s cap.  These numbers are lower by roughly half from where I was w/o bandwidth throttling but I'd still seen numbers that low before.   The only thing I could really see would tell me I was having bandwidth trouble was the droppedFrames count rising on the WebCamPublisher netStreamInfo.

So I'm wondering am I looking at the wrong thing?  I want to monitor my upstream bandwidth and adjust the audio quality of the Speex codec as well as the video settings to get better audio quality for the call.   I'd sacrifice all of my video, and most of my audio quality just to get intelligable audio in a low bandwidth situation.   I'm just looking for something I can relaibly measure to make that decision.

Anyone have an ideas, or can you point to what I might be doing wrong in my measurements?

Best Regards,



Level 4

Ah ok so answering my own question I guess.  The docs say currentBytesPerSecond and the like are how quickly the output buffer is filled so that really has nothing to do with how many bytes are actually making it out onto the link.   Is there some other metric I could use for this?