My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 157613: Microphone input is heavily distorted on numerous mic tests with Pepper
117 people starred this issue.
Comments by non-members will not trigger notification emails to users who starred this issue.
Back to list
 
Project Member Reported by nhu...@adobe.com, Oct 24, 2012

Flash version : Pepper 11.4.31.204
Chrome version: 23.0.1271.40 beta
OS            : Mac 10.7.3
URL/test case : http://ats.macromedia.com/Players/ATS/ATS10AS3/Shipping/ATS.html?testID=40827

Steps: 1.) Go to http://ats.macromedia.com/Players/ATS/ATS10AS3/Shipping/ATS.html?testID=40827
2.) Click Publish
3.) Allow Flash access to cam/mic and choose the built-in mic, or use a headset.
3.) Click Subscribe
4.) Tap or speak into the mic and listen to the output.

Expected:Audio output should accurately reflect input.

Observed:Audio sounds very distorted and noisy.
Oct 24, 2012
#1 nhu...@adobe.com
From Xing (at Adobe):

On Pepper, TeamSpirit Voice Engine is used to process input/output audio. For microphone, the input audio data comes from Chrome/PPAPI through AudioInput::AudioInputCallback. 

The problem does not happen on Windows, but only on Mac. The difference I noticed is that on Windows, each AudioInputCallback gives us 4410 bytes of data, but on Mac, we only get 1024 bytes, this is the main reason we hear distorted audio.
Oct 24, 2012
#2 nhu...@adobe.com
(No comment was entered for this change.)
Labels: -Pri-2 Pri-1
Oct 24, 2012
#3 jeffreyc@google.com
hey guys, are we still waiting on general Chrome audio-stack improvements in order to make progress here? What's the status of that?
Cc: viettrun...@chromium.org
Labels: Feature-Media-Audio OS-Mac
Oct 26, 2012
#4 jeffreyc@google.com
(No comment was entered for this change.)
Cc: crog...@google.com scherkus@chromium.org
Oct 26, 2012
#5 scherkus@chromium.org
jeffreyc: considering that WebRTC uses the same code path I'd expect either this to reproduce in WebRTC as well or at the least be a bug between the audio input code and pepper

henrika/xians: according to #1 this only happens on mac. is there a similar microphone loopback test for WebRTC? perhaps it's simply a bug in the mac input code?
Cc: xians@chromium.org henrika@chromium.org
Oct 26, 2012
#6 xians@chromium.org
+ Dale.

From M23 on Mac, we are opening the capture soundcard using 128 samples as buffer size and doing a resampling/FIFO above, the glitches might be generated when the OS could not handle the intensive callbacks.

nhuang, could you please tell us about your machine's CPU and memory?
Cc: dalecur...@chromium.org
Oct 26, 2012
#7 dalecur...@chromium.org
Per comment #1, it seems the problem is the AudioInputCallback is not getting the amount of data it expects.  Where is this size information controlled?  Could the low latency input device be returning too soon?
Oct 26, 2012
#8 nhu...@adobe.com
I'm using a MacBook Pro with the following GPU information. But I was able to reproduce this on other mac machines as well.

Software:  Mac OS X Lion 10.7.3 
Processor:  2.8 GHz Intel Core 2 Duo
Memory : 4 GB 1067 MHz DDR3
Graphics:  NVIDIA GeForce 9400M 256 MB
Oct 26, 2012
#9 dalecur...@chromium.org
Did this issue exist with M22 and pepper flash enabled?
Oct 26, 2012
#10 nhu...@adobe.com
This bug only is seen with Mac. M22 didn't have Pepper packaged with it yet.
Oct 26, 2012
#11 dalecur...@chromium.org
Doh, I thought you could optionally enable it if you went to chrome://plugins.
Oct 26, 2012
#12 xians@chromium.org
nhuang, do you mind installing canary on Mac and try it out https://tools.google.com/dlpage/chromesxs?platform=mac, our latest code has an internal buffer to handle the variation of the buffer size in AudioUnit, I wonder if it helps.
Oct 26, 2012
#13 nhu...@adobe.com
Unfortunately, it is reproducing in the latest version of canary as well. 

Mac 10.7.3 / Chrome 24.0.1308.0 canary / Pepper 11.5.31.101
Oct 26, 2012
#14 henrika@chromium.org
Andrew,

there are two levels of unit tests for WebRTC/media you can try.

1) content_unittets --gtest_filter=WebRTC* (one is a full-duplex test and
you can extend the time easily)
2) media_unittests --gtest_filter=AudioLowLatencyInputOutputTest
--gtest_also_run_disabled_test -> will give you 10 seconds loopback in
TEST_F(AudioLowLatencyInputOutputTest,
DISABLED_FullDuplexDelayMeasurement).
Oct 26, 2012
#15 xians@chromium.org
Thanks, nhuang. Could you please try out webrtc loopback to verify that it is pepper specific:
Open a tab with url:
https://apprtc.appspot.com/?debug=loopback
Click on allow in the infobar, then you should hear the loopback audio when it is in connected status.
Oct 26, 2012
#16 nhu...@adobe.com
Yes, it seems specific to Pepper. Mic feedback sounds fine in the webrtc loopback app. It also works fine if you disable Pepper and use the NPAPI plug-in instead.
Oct 26, 2012
#17 xians@chromium.org
Then the issues seems to be on the render side, Dale, any idea here?
Oct 26, 2012
#18 dalecur...@chromium.org
May be a bug with the pepper input API. I haven't ever looked at this. Is there a working pepper input example out there?
Oct 26, 2012
#19 dalecur...@chromium.org
VietTrung/Nicholas: Can you guys verify that the pepper input stuff is working somewhere?  Since WebRTC is working correctly, I'm inclined to believe there's a disconnect in the pepper impl vs AudioInputDevice.
Cc: nfulla...@chromium.org
Oct 27, 2012
#20 henrika@chromium.org
VietTrung/Nicholas: are there any unit tests for the Pepper input audio path which can be used to track down the degradation? If not, it seems like a good time to add. Also, as I recall it, there is a TODO to port Pepper over to the same backend as WebRTC for the capture parts. It could be a good idea to do that as well to ensure that we are always in phase and don't have to solve issues in two different paths.
Nov 5, 2012
#21 i...@tokbox.com
See also this bug:
https://code.google.com/p/chromium/issues/detail?id=158974

which contains additional information and attempts at various workarounds.
Nov 6, 2012
#22 phoglund@chromium.org
(No comment was entered for this change.)
Labels: webrtc-feedback
Nov 6, 2012
#23 tnakamura@chromium.org
(No comment was entered for this change.)
Labels: -webrtc-feedback not-webrtc
Nov 8, 2012
#24 orth.m...@gmail.com
Still an issue with the latest Chrome 23 release using pepper Flash Player 11.5.31.
Flash Player 11.5.502 and higher w/o pepper works fine.
Nov 8, 2012
#25 v...@powhow.com
When is the target fix for this?  We are having this issue too.
Nov 8, 2012
#26 dalecur...@chromium.org
 Issue 160161  has been merged into this issue.
Nov 8, 2012
#27 dalecur...@chromium.org
 Issue 159881  has been merged into this issue.
Cc: sail@chromium.org
Nov 8, 2012
#28 dalecur...@chromium.org
To xians; can you please sanity check the non low-latency audio input path on mac?
Status: Assigned
Owner: xians@chromium.org
Nov 8, 2012
#29 dalecur...@chromium.org
(No comment was entered for this change.)
Labels: Mstone-23
Nov 9, 2012
#30 henrika@chromium.org
Patched the existing full-duplex audio test. See https://codereview.chromium.org/11360168/ for details.
It is now possible to do:

TEST=media_unittests.exe --gtest_filter=AudioLow* --gtest_also_run_disabled_tests

on Mac with audio hardware and try out the real-time quality for the low-latency path.

I did some minor local modifications and tested different buffer sizes on my desktop Mac 10.8. I also tried different sample rates and audio devices.
On my machine 1024 sounded perfect but 512 was choppy. I was not able to provoke bad audio at 1024 for any case.

How to replicate my test?

Get version later than https://src.chromium.org/viewvc/chrome?view=rev&revision=166906

Search for format_(AudioParameters::AUDIO_PCM_LOW_LATENCY), and replace AUDIO_PCM_LOW_LATENCY by AUDIO_PCM_LINEAR.

Search for samples_per_packet_ = StreamTraits::HardwareBufferSize(); and use any size you want, e.g: samples_per_packet_ = 1024;

Run and listen to your own voice in loopback.

To summarize: 1024 seems like an OK buffer size for the high-latency input path but more tests are required on less powerful hardware and using a more realistic Pepper client.
Nov 9, 2012
#31 xians@chromium.org
(No comment was entered for this change.)
Status: Started
Nov 12, 2012
#32 dalecur...@chromium.org
@nhuang: Can you provide some details on your audio input settings as reported by the audio midi setup utility? E.g. sample rate, bit depth, channels, etc. Also to confirm, the 1024 number you report in the original report is in bytes and not frames?
Nov 12, 2012
#33 rok.gregoric
This problem is affecting chrome v23 on mac with pepper flash plugin enabled (PPAPI). You can test it here: http://vocaroo.com

My chrome://plugins for the broken plugin:
Shockwave Flash 11.5 r31
Name:	Shockwave Flash
Description:	Shockwave Flash 11.5 r31
Version:	11.5.31.2
Location:	/Applications/Google Chrome.app/Contents/Versions/23.0.1271.64/Google Chrome Framework.framework/Internet Plug-Ins/PepperFlash/PepperFlashPlayer.plugin
Type:	PPAPI (out-of-process)


If I disable the PPAPI plugin and try to run the same test with the NPAPI plugin ... it works perfectly!
Nov 12, 2012
#34 nhu...@adobe.com
I am using the built in mic on a MacBook Pro with the following format:

44100.0 Hz / 2 ch-16bit Integar

The 1024 number is indeed bytes.


Nov 13, 2012
#36 oron...@gmail.com
Hi,

Having major issues with it as well.

Details are:
Chrome - 23.0.1271.64
Flash - 11.5.31.2
OS - 10.7.5

Examples in YouTube:
https://www.youtube.com/watch?v=3ugdk89ojxU

Any chance for a work around?
Thanks!
Nov 13, 2012
#37 RMacas...@gmail.com
I was able to reproduce the mic audio problem easily, on different machines, using the latest version of Mac Chrome and Pepper. I'm curious if the repeated "Can you provide me details about audio input setting?" questions are because Google/Adobe team members are having problems reproducing it, or because it's a problem that plagues a subset of machines.

This seems like a major blocker for any company/product dependent on Mic input. I'm probably stating the obvious already and will likely upset many people... but I'm not sure how this wasn't caught ahead of time/taking so long to resolve.
Nov 13, 2012
#38 rok.gregoric
I am using the microphone instance with the following parameters (that result in distorted sound):
gain = 100;
rate = 44;
silenceLevel = 0;
timeOut = 4000;
Nov 13, 2012
#39 Prave...@tokbox.com
I agree this is a blocking issue and it should be P0 -- chrome 23 comes with pepper plugin enabled and may be they should consider reverting the default to enable the NPAPI as it was with chrome 22 until they fix this issue.
Nov 13, 2012
#40 gus...@fluencyforums.com
This is affecting a great portion of our user base on Verbling, rendering the site close to useless for them. I agree that the severity of this bug should P0.
Nov 14, 2012
#41 andypap...@gmail.com
I agree with the last few comments. This is a severe issue and one that should be addressed immediately.

Nov 15, 2012
#42 will2...@gmail.com
This is a major issue and a fix should be a top priority. There are many businesses and individuals that are being affected by this and it's forcing them to use another browser entirely. Please resolve this as soon as possible, 
Nov 15, 2012
#43 xians@chromium.org
There are multiple problems behind this audio issue:
# Sometimes flash is using a buffer size which is too small for the high latency audio path.
# The high latency IO implementation can deliver callbacks consecutively in a very short interval, and the audio data can be over written if the client does not fetch the data quick enough.

Dale proposed some solutions in an email thread, I am going to assign to Dale to decide which one to choose.
Owner: dalecur...@chromium.org
Nov 15, 2012
#44 k...@jamstar.co
Hi, 
We're using the mic as well..having simular issues, ONLY with Pepper-based Flash Player in chrome.
Other new flash players works great.
It's killing our business! what should we do???
Nov 15, 2012
#45 will2...@gmail.com
In the meantime, please consider reverting to the settings as it was in Chrome 22. Right now this is causing more issues to web based businesses and their customers then you can imagine. Please at least revert back to Chrome 22 settings until a proper fix is released. Thank you! 
Nov 15, 2012
#46 jus...@chromatik.com
Does anyone have working code for getUserMedia({audio:true},function(stream) { /* get stream.audioTracks as buffer, byte array, or anything? */ });



Nov 15, 2012
#48 rok.gregoric
You should enable 'Web Audio Input' under chrome://flags to make it work.
Nov 15, 2012
#49 jus...@chromatik.com
It brings up the accept dialog and has an audio tag with the generated blob, seems to play the proper about of time but can't hear anything.  Speakers are on :)  
Nov 15, 2012
#50 rok.gregoric
Did you enable Web Audio Input in chrome://flags and restarted chrome?
Nov 15, 2012
#51 bugdro...@chromium.org
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=168106

------------------------------------------------------------------------
r168106 | dalecurtis@google.com | 2012-11-16T02:02:31.210923Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_input_mac.h?r1=168106&r2=168105&pathrev=168106

Reduce high latency input buffers to 1.

Multiple buffers lead to trampling input data which is in the process
of being transmitted across the shared memory.

Since this API was never intended for low latency usage, clients should
instead use a larger buffer size. At least 2048 @ 44.1kHz (Flash) and
1600 at 16kHz (speech recognizer).

vtl will land a fix to flash along side this change to move it off of the
RecommendSampleCount() method to a hard coded 2048 frame buffer.

NOTRY=true
BUG=157613
TEST=input is clear and crisp w/ flash @ 2048 buffer.

Review URL: https://codereview.chromium.org/11418017
------------------------------------------------------------------------
Nov 16, 2012
#52 blakebis...@gmail.com
What about the acoustic echo issue that has been plaguing us for several months now? https://code.google.com/p/chromium/issues/detail?id=152314

Sorry to cross-post, but the other bug has seen no activity and it's just as important. Those of you with real-time audio chat businesses, if you don't use headphones, you'll get acoustic echo that absolutely derails the ability to converse. In our business, one side of the conversation cannot use headphones because multiple people are on that one side and must all be able to hear what the other side is saying.
Nov 16, 2012
#53 jus...@chromatik.com
@rok  I got it to work, but only if my headphones are in.  If they aren't in the wav that is generated is silent, but of the correct link.

The pepper issue seems fixed in Canary currently.

Nov 16, 2012
#54 rok.gregoric
@jus .. great .. I tried it now and it works for me too .. hope to see the pepper issue in the stable chrome ASAP.
Nov 16, 2012
#55 Prave...@tokbox.com
nice to see the issue fixed in canary and hopefully get this fix patched soon to stable chrome.  

One thing i want to share re: comment #50 -- enabling Web Audio Input in chrome://flags and restarting chrome does not fix the issue - the audio continue to be distorted. 


Nov 16, 2012
#56 rok.gregoric
comment #50 is related to comment #46,47,48,49
Nov 18, 2012
#57 GuyZis...@gmail.com
Using pepper (PPAPI ver 11.5.31.130) on chrome canary  25.0.1328.0 the issue persists.
See this:
https://www.youtube.com/watch?v=K9nwwTlDI6s
Nov 18, 2012
#58 ruipmari...@gmail.com
I can also reproduce this on Chrome Canary 25.0.1328 just like the user from comment #57. Recording audio using the demo from comment #33 (http://vocaroo.com/) produces robotic sound.

From chrome://flash:

Google Chrome	25.0.1328.0 (canary)
OS	Mac OS X
Flash plugin	11.5.31.130 /Applications/Google Chrome Canary.app/Contents/Versions/25.0.1328.0/Google Chrome Framework.framework/Internet Plug-Ins/PepperFlash/PepperFlashPlayer.plugin
Nov 19, 2012
#59 will2...@gmail.com
I am also able to reproduce this issue in Version 25.0.1329.0 of canary. Please, if you can address this issue in a timely fashion, I'm sure many of us would really appreciate it.
Nov 19, 2012
#60 rok.gregoric
Chrome Version 25.0.1329.0 canary with Flash 11.5.31.130 works for me .. I am not able to reproduce the distorted sound while recording.

Nov 19, 2012
#61 will2...@gmail.com
I'm still experiencing this issue running Flash Version 11.5.502.110 and Canary 25.0.1329.0 on Mac. Thanks
Nov 19, 2012
#62 rok.gregoric
Google Chrome	25.0.1329.0 (canary)
OS	Mac OS X
Flash plugin	11.5.31.130
Flash plugin	11.5.502.110

Both versions work OK for me.
Nov 19, 2012
#63 jst...@gmail.com
Hi any update on this bug?
When can the fix be landed on Production Chrome 23?

Thanks
Nov 20, 2012
#64 Chicohu...@gmail.com
Our users on FaceFlow are bombarding us with complaints about this issue... We tell them to use another browser temporarily - not what should be happening! Please get a fix soon. 
Nov 20, 2012
#65 w...@liveninja.com
Our users too. It's a huge issue effecting not only our business, but as a platform it effects our customers business as well. Please make this bug a priority. We need it on the production version ASAP! Thank you.
Nov 20, 2012
#66 rok.gregoric
Our users are also complaining .. We chose chrome for it's consistency and fast updates .. not the case here.
Nov 20, 2012
#67 Tomaz.St...@gmail.com
This issue has been reported on Oct 24, 2012. That is 27 days ago, way before 23 was GA. Shipping a product with this kind of issue is not what one would expect from the Chrome team, specially since there was a working solution available.

It is obviously affecting several businesses and (my guess is) a few million users in total. It would be great to get at least some information on the current status of the bug fixing efforts and get an ETA for the update.

I believe we all appreciate your effort, but we need more information on when a fix is expected and if any activity is in progress to deliver it in a short timeframe.
Nov 21, 2012
#69 g...@kwalitools.com
Helo, +1 here on the topic. This bug effects many client of ours. Could you please provide an ETA what we can pass to our clients?
Thanks,
Greg
Nov 21, 2012
#70 rbha...@mivoko.com
I agree with the concerns expressed. This is a serious issue that I request be addressed immediately.
Nov 21, 2012
#71 will2...@gmail.com
Same here. Please just quickly provide us with an estimated time frame for resolving this issue. It's of huge importance. Just a quick indication would go a long way at this point. Thank you.
Nov 22, 2012
#72 davidkom...@gmail.com
I agree. The impact will be big from having this fixed!
Nov 23, 2012
#73 will2...@gmail.com
I can confirm that the issue seems to be resolved in Chrome Canary  25.0.1333.0. Please let us know an estimated time frame of when we can expect this to be pushed to the production version of Chrome. Thanks!
Nov 26, 2012
#74 eng...@chromium.org
 Issue 158974  has been merged into this issue.
Cc: eng...@chromium.org
Nov 26, 2012
#75 eng...@chromium.org
 Issue 159888  has been merged into this issue.
Nov 26, 2012
#76 rok.gregoric
Today I tried all 3 latest versions of chrome:

Google Chrome	23.0.1271.64 ()
OS	Mac OS X
Flash plugin	11.5.31.2 /Applications/Google Chrome.app/Contents/Versions/23.0.1271.64/Google Chrome Framework.framework/Internet Plug-Ins/PepperFlash/PepperFlashPlayer.plugin

Google Chrome	24.0.1312.5 (beta)
OS	Mac OS X
Flash plugin	11.5.31.101 /Applications/Google Chrome Beta.app/Contents/Versions/24.0.1312.5/Google Chrome Framework.framework/Internet Plug-Ins/PepperFlash/PepperFlashPlayer.plugin

Google Chrome	25.0.1335.0 (canary)
OS	Mac OS X
Flash plugin	11.5.31.131 /Applications/Google Chrome Canary.app/Contents/Versions/25.0.1335.0/Google Chrome Framework.framework/Internet Plug-Ins/PepperFlash/PepperFlashPlayer.plugin

All of them suffer from this issue.

I am really disappointed how you are handling this pretty important bug affecting millions of users around the world.

Can somebody reply here when the fix will be available and if you are even working on it?
Nov 26, 2012
#77 sail@chromium.org
> Can somebody reply here when the fix will be available and if you are even working on it?

Thanks for the detailed report. I'll ping dalecurtis and update this bug with the latest status.
Nov 26, 2012
#78 sail@chromium.org
Dale says that he's waiting for Trung to update the Flash build.
Owner: viettrun...@chromium.org
Nov 26, 2012
#79 k...@jamstar.co
Chromium Guys, 
It's been almost 3 weeks that we're keep losing chrome users - a major chunk of our users of-course.
Can you please provide ETA for fix in stable chrome. REALLY REALLY important for us,
Thanks!!
Nov 26, 2012
#80 oron...@gmail.com
I concur, meanwhile we have to recommend users on other browsers. 
It's a pity!
Nov 26, 2012
#81 leigh30...@yahoo.com
Hi,

Why does Google Chrome not fix this?  and it is real stupid to force a flash player on us that does not work properly.  I do not like the fact that a bad flash player comes with Chrome anyway. They should make it seperate from Chrome. We should be able to download our own updates.
Nov 27, 2012
#82 will2...@gmail.com
Hi sail@chromium.org and the rest of the chromium team,

Thanks for your note regarding the update to the flash build. Are you able to tell us some form of ETA or time frame when you expect this issue to be resolved and pushed to production Chrome? Even just a ballpark figure  or a rough estimate would be very helpful at this point as you can tell by all of the concerned comments here. 

Thank you!
Nov 28, 2012
#83 parth.bh...@gmail.com
We are also facing major issues and it is preventing anyone with Chrome from using our service. Hoping for a bug fix or ETA soon as we are losing tons of users every day.

Thank you!
Nov 28, 2012
#85 var...@gmail.com
we're also seeing lots of user complaints about this.  Please fix soon. :-(
Nov 28, 2012
#86 mi...@mishaleybovich.com
Agreed, this is super annoying.  In the meantime, if it's useful to anyone, check out what we did at Meograph to at least tell users what's going on:

1) Create an account at www.meograph.com using Chrome
2) Create a Meograph
3) Add a moment
4) Click on the Narration tab at the top of the player
5) Click on link saying "Recording Problems?" (only visible in Chrome) ... this brings up a modal that explains how to fix.

After doing this, we stopped getting complaints about the problem at least :)
Nov 28, 2012
#87 viettrun...@chromium.org
I believe this should generally be fixed on the current Canary. We'll ponder merging it to the M23 update.
Status: Fixed
Nov 29, 2012
#88 will2...@gmail.com
Yes, this is fixed on the current Canary but still nothing on the production version of Chrome. Again, an ETA of when we can expect this to be resolved will be a huge help to all that are on this thread. Thank you.
Nov 29, 2012
#89 jeffreyc@google.com
It depends on whether we merge it to the M23 branch and/or the M24 branch. If it just stays on Canary (currently M25), then it will ride the M25 release train.

If it gets merged to M23, then it would be in the next Stable channel update, which would likely be sometime in the next couple weeks.

If it gets merged to M24 (but not M23), then it would hit the Stable channel sometime in January.

If it stays on M25 only, then it would hit the Stable channel sometime in February.
Nov 29, 2012
#90 will2...@gmail.com
Ok, with that now being known I implore you to PLEASE merge it to M23. 

As you can see by this thread, many businesses and millions of their customers are being effected by this. I don't think the other participants on this thread can afford to have this remain an issue until February. Please do whatever you can to merge this with the M23 update. Its of extreme importance to us all. Thank you.
Nov 29, 2012
#91 v...@powhow.com
Second that last comment re merging to M23!
Nov 29, 2012
#92 mi...@mishaleybovich.com
At the risk of being annoying with piling on, doing so only to emphasize the importance of fixing this soon not in February, THIRDING the merge into M23!
Nov 29, 2012
#93 Tomaz.St...@gmail.com
@Jeffreyc - are you guys just so out of touch that you really don't see what is going on and how critical this issue is for a series of businesses and the people that use those products?

After releasing a version with a critical bug that has been reported before the release, it took you 35 days to get to fix instead of switching to non Pepper Flash the next day as default and now you are contemplating of merging this into a version that is going to be released in a few weeks or a few months? 

This feels like a very bad joke to me (and I guess a few other people). I can understand that bugs happen, but taking such a long time to fix something this critical is just unacceptable, if you want anyone to trust you enough to build on your platform. 

Get the fix out asap.
Nov 29, 2012
#94 dfe...@gmail.com
FOURTHING merge into M23. This is a business-critical bug fix for a lot of companies. We're being forced to direct our users to different browsers. We really like Chrome and would love to continue to have it in our supported browser list.
Nov 29, 2012
#95 paul.chr...@gmail.com
Please merge this into M23, Our site is seriously being affected by this bug!
Nov 29, 2012
#96 ffdixon@gmail.com
I'm one of the devs on BigBlueButton, an open source web conferencing system.  The BigBlueButton client is flash based, and we use Chrome and Firefox quite heavily for development and testing.

There is always a balancing act for quality vs. delivery dates.   We're anxious as others to see Chrome updated.  But from a quality point of view, take whatever time you need to ensure it's properly fixed.  

Chrome is a great browser, and it will be even better after after this bug is fixed in stable, whatever the release.
Nov 29, 2012
#97 j...@klip.com
An interesting read on how one company tried to workaround the bug:  http://codeartists.com/post/36746402258/how-to-record-audio-in-chrome-with-native-html5-apis
Nov 29, 2012
#98 rok.kru...@gmail.com
We also prepared YouTube explainer for our users how to get around this
problem

http://youtu.be/V-1h2nU-KKY

And showed a big notification window when detecting the problematic browser.

Rok Krulec
Nov 29, 2012
#99 kar...@google.com
approved for m23. pls change to m24 and requested once it's merged.
Labels: Merge-Approved
Nov 29, 2012
#100 dalecur...@chromium.org
(No comment was entered for this change.)
Labels: -Mstone-23 Mstone-24
Nov 29, 2012
#101 dalecur...@chromium.org
@dharani, okay to merge m24?
Labels: -Merge-Approved Merge-Requested
Nov 29, 2012
#102 bugdro...@chromium.org
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=170321

------------------------------------------------------------------------
r170321 | dalecurtis@google.com | 2012-11-30T01:15:44.306819Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1271/src/media/audio/mac/audio_input_mac.h?r1=170321&r2=170320&pathrev=170321

Merge 168106 - Reduce high latency input buffers to 1.

Multiple buffers lead to trampling input data which is in the process
of being transmitted across the shared memory.

Since this API was never intended for low latency usage, clients should
instead use a larger buffer size. At least 2048 @ 44.1kHz (Flash) and
1600 at 16kHz (speech recognizer).

vtl will land a fix to flash along side this change to move it off of the
RecommendSampleCount() method to a hard coded 2048 frame buffer.

NOTRY=true
BUG=157613
TEST=input is clear and crisp w/ flash @ 2048 buffer.

Review URL: https://codereview.chromium.org/11418017

TBR=dalecurtis@google.com
Review URL: https://codereview.chromium.org/11411274
------------------------------------------------------------------------
Labels: merge-merged-1271
Dec 3, 2012
#103 dhar...@google.com
(No comment was entered for this change.)
Labels: -Merge-Requested Merge-Approved
Dec 3, 2012
#104 bugdro...@chromium.org
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=170808

------------------------------------------------------------------------
r170808 | dalecurtis@google.com | 2012-12-03T21:04:33.450341Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1312/src/media/audio/mac/audio_input_mac.h?r1=170808&r2=170807&pathrev=170808

Merge 168106
> Reduce high latency input buffers to 1.
> 
> Multiple buffers lead to trampling input data which is in the process
> of being transmitted across the shared memory.
> 
> Since this API was never intended for low latency usage, clients should
> instead use a larger buffer size. At least 2048 @ 44.1kHz (Flash) and
> 1600 at 16kHz (speech recognizer).
> 
> vtl will land a fix to flash along side this change to move it off of the
> RecommendSampleCount() method to a hard coded 2048 frame buffer.
> 
> NOTRY=true
> BUG=157613
> TEST=input is clear and crisp w/ flash @ 2048 buffer.
> 
> Review URL: https://codereview.chromium.org/11418017

TBR=dalecurtis@google.com
Review URL: https://codereview.chromium.org/11411329
------------------------------------------------------------------------
Labels: -Merge-Approved merge-merged-1312
Dec 5, 2012
#105 will2...@gmail.com
Thanks very much for merging this with M23.  Any update on a ballpark timeframe on when this should be pushed to the production Chrome? 

Again, thanks for getting this resolved and pushed out. We all VERY much appreciate it. 
Dec 5, 2012
#106 jeffreyc@google.com
I believe we will have an M23 Stable update in the next week or so.
Dec 5, 2012
#107 pbommana@chromium.org
I am still able to reproduce the bug. 

Steps : 
-------------
1. Installed chrome 23.0.1271.97 on Macbook pro(non retina)with 10.8.2
2. Open the website http://www.vocaroo.com
3. Click to record
4. listen to the recorded voice.

Observed:Audio sounds very distorted and noisy.

I was unable to use the provided URL from initial bug report. 

Status: Assigned
Dec 5, 2012
#108 vivi...@chromium.org
tested on http:www.voraroo.com/, status so far:

New Retina Mac Air 10.8.2 - issue NO longer exist
New Retina Mac Pro 10.8.2 - issue NO longer exist
New Retina Mac Pro 10.7 - issue NO longer exist

Old non-Retina Mac Air 10.8.2 - issue REPRO
Old non-Retina Mac Pro 10.8.2 - issue REPRO

still trying or more machine to see if we can narrow down more specific type of machine that still has this issue

Dec 6, 2012
#109 bugdro...@chromium.org
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=171681

------------------------------------------------------------------------
r171681 | dalecurtis@google.com | 2012-12-07T01:38:39.718858Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_input_mac.h?r1=171681&r2=171680&pathrev=171681
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_input_mac.cc?r1=171681&r2=171680&pathrev=171681

Delay delivery of audio input data.

The AudioQueue API may use a large internal buffer and repeatedly call us
back to back once that internal buffer is filled.  When this happens the
renderer client does not have enough time to read data back from the
shared memory before the next write comes along.  If HandleInputBuffer()
is called too frequently, Sleep() to simulate realtime input and ensure
the shared memory doesn't get trampled.

BUG=157613
TEST=Playback works on older style Mac units.

Review URL: https://codereview.chromium.org/11482002
------------------------------------------------------------------------
Dec 6, 2012
#110 bugdro...@chromium.org
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=171692

------------------------------------------------------------------------
r171692 | tzik@chromium.org | 2012-12-07T04:44:05.231261Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_input_mac.h?r1=171692&r2=171691&pathrev=171692
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_input_mac.cc?r1=171692&r2=171691&pathrev=171692

Revert 171681
> Delay delivery of audio input data.
> 
> The AudioQueue API may use a large internal buffer and repeatedly call us
> back to back once that internal buffer is filled.  When this happens the
> renderer client does not have enough time to read data back from the
> shared memory before the next write comes along.  If HandleInputBuffer()
> is called too frequently, Sleep() to simulate realtime input and ensure
> the shared memory doesn't get trampled.
> 
> BUG=157613
> TEST=Playback works on older style Mac units.
> 
> Review URL: https://codereview.chromium.org/11482002

TBR=dalecurtis@google.com
Review URL: https://codereview.chromium.org/11478019
------------------------------------------------------------------------
Dec 6, 2012
#111 bugdro...@chromium.org
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=171701

------------------------------------------------------------------------
r171701 | dalecurtis@google.com | 2012-12-07T06:24:32.993366Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_input_mac.h?r1=171701&r2=171700&pathrev=171701
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_input_unittest.cc?r1=171701&r2=171700&pathrev=171701
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_input_mac.cc?r1=171701&r2=171700&pathrev=171701

Delay delivery of audio input data.

The AudioQueue API may use a large internal buffer and repeatedly call us
back to back once that internal buffer is filled.  When this happens the
renderer client does not have enough time to read data back from the
shared memory before the next write comes along.  If HandleInputBuffer()
is called too frequently, Sleep() to simulate realtime input and ensure
the shared memory doesn't get trampled.

BUG=157613
TEST=Playback works on older style Mac units.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=171681

Review URL: https://codereview.chromium.org/11482002
------------------------------------------------------------------------
Dec 7, 2012
#112 vivi...@google.com
flash microphone input works FINE on 25.0.1352.0 latest canary , tested on following Mac:

Old Mac Pro OSX 10.8
Old Mac Air OSX 10.8
Old Mac Pro OSX 10.6
New Retina Mac Air 10.8
New Retina Mac Pro 10.8
New Retina Mac Pro 10.7
also try 25.0.1352.0 on Win 7 ,works fine as well. this bug is verified as fixed in Canary.
Dec 10, 2012
#113 dhar...@google.com
Approved r171701 for M24 branch.
Labels: -merge-merged-1312 Merge-Approved
Dec 10, 2012
#114 RMacas...@gmail.com
Is there a target date for m24 to go to prod?
Dec 10, 2012
#115 dalecur...@chromium.org
We're soaking the change in M24 before merging to M23.
Dec 10, 2012
#116 bugdro...@chromium.org
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=172093

------------------------------------------------------------------------
r172093 | dalecurtis@google.com | 2012-12-10T18:57:06.477140Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1312/src/media/audio/audio_input_unittest.cc?r1=172093&r2=172092&pathrev=172093
   M http://src.chromium.org/viewvc/chrome/branches/1312/src/media/audio/mac/audio_input_mac.cc?r1=172093&r2=172092&pathrev=172093
   M http://src.chromium.org/viewvc/chrome/branches/1312/src/media/audio/mac/audio_input_mac.h?r1=172093&r2=172092&pathrev=172093

Merge 171701
> Delay delivery of audio input data.
> 
> The AudioQueue API may use a large internal buffer and repeatedly call us
> back to back once that internal buffer is filled.  When this happens the
> renderer client does not have enough time to read data back from the
> shared memory before the next write comes along.  If HandleInputBuffer()
> is called too frequently, Sleep() to simulate realtime input and ensure
> the shared memory doesn't get trampled.
> 
> BUG=157613
> TEST=Playback works on older style Mac units.
> 
> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=171681
> 
> Review URL: https://codereview.chromium.org/11482002

TBR=dalecurtis@google.com
Review URL: https://codereview.chromium.org/11509004
------------------------------------------------------------------------
Labels: -Merge-Approved merge-merged-1312
Dec 11, 2012
#117 bugdro...@chromium.org
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=172428

------------------------------------------------------------------------
r172428 | dalecurtis@google.com | 2012-12-11T22:17:30.901916Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1271_97/src/media/audio/audio_input_unittest.cc?r1=172428&r2=172427&pathrev=172428
   M http://src.chromium.org/viewvc/chrome/branches/1271_97/src/media/audio/mac/audio_input_mac.cc?r1=172428&r2=172427&pathrev=172428
   M http://src.chromium.org/viewvc/chrome/branches/1271_97/src/media/audio/mac/audio_input_mac.h?r1=172428&r2=172427&pathrev=172428

Merge 171701
> Delay delivery of audio input data.
> 
> The AudioQueue API may use a large internal buffer and repeatedly call us
> back to back once that internal buffer is filled.  When this happens the
> renderer client does not have enough time to read data back from the
> shared memory before the next write comes along.  If HandleInputBuffer()
> is called too frequently, Sleep() to simulate realtime input and ensure
> the shared memory doesn't get trampled.
> 
> BUG=157613
> TEST=Playback works on older style Mac units.
> 
> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=171681
> 
> Review URL: https://codereview.chromium.org/11482002

TBR=dalecurtis@google.com
Review URL: https://codereview.chromium.org/11546002
------------------------------------------------------------------------
Labels: merge-merged-1271_97
Dec 11, 2012
#118 nyerrami...@chromium.org
Able to repro this issue on Stable 23.0.1271.110 on Mac 10.8.2,Flash version : Pepper 11.5.31.5

Tested with http://vocaroo.com 
Enable the PPAPI pluign  -- not working (Audio sounds very distorted and noisy)
Disable the PPAPI plugin and try to run the same test ... working perfectly.


Note : it is working fine in Canary 25.0.1357.0 o for PPAPI enabled and disabled

Cc: nyerrami...@chromium.org
Dec 11, 2012
#119 nyerrami...@chromium.org
just to add -- tested on Macbook pro (OS 10.8.2)
Dec 12, 2012
#121 pbommana@chromium.org
The issue is fixed.Verified on MacBook pro Retina and Non-retina with MacOS 10.8.2 with Chrome 23.0.1271.101. 

Also tested by enabling and disabling PPAPI plugin and it works fine.







Dec 12, 2012
#122 rok.gregoric
Just tried the new version. It's working much better, but still not perfect. I can hear some distortion here and there.

I am running:
Google Chrome	23.0.1271.97 ()
OS	Mac OS X
Flash plugin	11.5.31.5 /Applications/Google Chrome.app/Contents/Versions/23.0.1271.97/Google Chrome Framework.framework/Internet Plug-Ins/PepperFlash/PepperFlashPlayer.plugin
Flash plugin	11.5.502.136 /Applications/Google Chrome.app/Contents/Versions/23.0.1271.97/Google Chrome Framework.framework/Internet Plug-Ins/Flash Player Plugin for Chrome.plugin (not used)
Flash plugin	11.5.502.136 /Library/Internet Plug-Ins/Flash Player.plugin (not used)

on MacBook pro Retina 13''.
Dec 13, 2012
#123 Tomaz.St...@gmail.com
Second Rok's comment, several users still reporting problems with distorted sound, all using the Pepper plugin.


Dec 16, 2012
#124 k...@jamstar.co
Tested on production chrome ver. 23.0.1271.97 @ Mac 13" OSx.
Works fine.

Dec 17, 2012
#125 benweeke...@googlemail.com

We have tested on a range of Macs. 23.0.1271.97 is much better but still not perfect.
To test simply go here pim-uat-09.requestec.com/qa and press Connect / Call to hear yourself coming back over RTMFP (UDP).

The good news is that audio and video are in synch when Enhanced Mic is enabled. This is still not the case on Windows using any version of Chrome (Canary included). Is that still being worked on?




Dec 17, 2012
#126 marsde...@gmail.com
Now with the last fix there seems to be a problem with the Audio completely dropping out after about 2 mins of working fine. It starts with some garbling and pop noises then completely drops.

Can you guys look into this asap please.

Try running a meeting with a friend on meetings.io with Chrome and see it happen - then test on any other browser to see it work fine.
Dec 18, 2012
#127 suh...@qibla.com
Same problem as comment 126, audio sounds find but then drops off completely at around the 2 minute mark.

Reproducable by testing with vocaroo.com.

iMac OS-X 10.7.5 with  Chrome Version 23.0.1271.101.
Dec 19, 2012
#128 dalecur...@chromium.org
I can reproduce this, but I'm not sure why it's failing. OSX is indeed returning silence to us after a minute or two. vocaroo.com maxed out at 1m30s for me w/o issue, but using http://www.jordansthings.com/blog/?p=5 I could verify the issue. Dumping raw input data directly from OSX shows it's returning silence and that the issue isn't lower in Chromium or Flash code.

I suspect OSX doesn't like us retiming the audio data for consistent delivery via Sleep. I'll discuss with some of our OSX guys to see what we can do.
Owner: dalecur...@chromium.org
Dec 20, 2012
#129 tinycha...@gmail.com
Does the issue with OSX dropping audio occur on other flash audio? Try http://tinychat.com - It may be a codec issue perhaps?
Dec 24, 2012
#130 marsde...@gmail.com
Comment 126 - this is a deal breaker for lots of peeps using flash for communications - when the audio drops out there's nothing left but very frustrated users who blame us. Can you guys get onto this asap? We're dying here with all these core bugs that's breaking everything that essential for a great communication experience.

BTW - happy holidays, but please fix as soon as you guys are back on deck :)
Dec 31, 2012
#131 Tomaz.St...@gmail.com
@dalecurtis - the issue does not occur if you disable Pepper in Chrome plugins. The issue does not occur in Firefox or Safari either.

This makes communication products relying on Flash in Chrome fairly useless. It would be great to have an ETA on the fix as several users have been complaining.

p.s.: Is there a good reason why you couldn't just have stayed with non-Pepper in production builds until these kind of issues would have been resolved?
Jan 8, 2013
#132 will2...@gmail.com
After the latest update of production Chrome (during the last 3-4 days) we are now experiencing some major audio and echo issues. My CTO seems to think it might be because the recently merged branch is conflicting with the recently pushed pepper fix. This is happening only in Chrome as all other browsers seem to function correctly. Please let me know if anyone else is experiencing this issue and Chrome team, please provide an update as soon as you can.

Thanks again!
Jan 8, 2013
#133 an...@tokbox.com
We've also had customers reporting major echo issues just as Comment #132 points out. I've been able to reproduce this myself. Here are the details:

User 1: Chrome 23.0.1271.101, Mac OS X 10.8, PepperFlashPlayer enabled
User 2: Chrome 23.0.1271.101, Mac OS X 10.7, PepperFlashPlayer enabled

1) Both users vist http://www.opentokfire.com and enter a room and start video.
2) Observe terrible  echo.

Then disabling the PepperFlashPlayer plugin for both users seemed to fix the issue.

Here are the details of the PepperFlashPlayer Plugin:


Adobe Flash Player (3 files) - Version: 11.5.502.136
Shockwave Flash 11.5 r502
Name:	Shockwave Flash
Description:	Shockwave Flash 11.5 r31
Version:	11.5.31.5
Location:	/Applications/Google Chrome.app/Contents/Versions/23.0.1271.101/Google Chrome Framework.framework/Internet Plug-Ins/PepperFlash/PepperFlashPlayer.plugin
Type:	PPAPI (out-of-process)
 	 Disable
MIME types:	
MIME type	Description	File extensions
application/x-shockwave-flash	Shockwave Flash	
.swf
application/futuresplash	FutureSplash Player	
.spl
Jan 8, 2013
#134 msan...@tokbox.com
I have reported the audio dropping issues in a new ticket.

https://code.google.com/p/chromium/issues/detail?id=168859
Jan 16, 2013
#135 kjellander@chromium.org
(No comment was entered for this change.)
Labels: not-speechapi
Jan 21, 2013
#136 deng...@gmail.com
We're having the same issue as post #133 with the latest stable build of Chrome:

Chrome 24.0.1312.52, Mac OS X 10.8.2, PepperFlashPlayer Enabled

When PepperFlashPlayer is disabled, the audio is fine and there is no echo. 

Details for PepperFlashPlayer plugin:

Adobe Flash Player (2 files) - Version: 11.5.502.146
Shockwave Flash 11.5 r502
Name:	Shockwave Flash
Description:	Shockwave Flash 11.5 r31
Version:	11.5.31.137
Location:	/Applications/Google Chrome.app/Contents/Versions/24.0.1312.52/Google Chrome Framework.framework/Internet Plug-Ins/PepperFlash/PepperFlashPlayer.plugin
Type:	PPAPI (out-of-process)
 	 Enable
MIME types:	
MIME type	Description	File extensions
application/x-shockwave-flash	Shockwave Flash	
.swf
application/futuresplash	FutureSplash Player	
.spl

This is a pretty bad bug so a quick resolution is greatly appreciated. 
Jan 23, 2013
#137 bugdro...@chromium.org
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=178517

------------------------------------------------------------------------
r178517 | dalecurtis@chromium.org | 2013-01-24T04:49:43.508572Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/mac/audio_input_mac.cc?r1=178517&r2=178516&pathrev=178517

Limit OnData() callbacks to every 5ms for mac audio input.

OSX doesn't like the audio data being retimed and we apparently can
not have Flash use a larger buffer size...  So this hack ensures each
OnData() call has time to deliver audio data to the renderer without
it being smashed by the next call.  5ms was chosen since we use the
same value for a similar hack in AlsaPcmOutputStream.

This is not ideal and instead Pepper input clients should be using at
least a 4k buffer on OSX until switched to the low latency pipeline.

There's no guarantee that the audio input stream won't drop out at a
much later time, but in local testing it's much greater than the 1.5
minutes to dropout we have now.

BUG=157613,168859
TEST=audio input doesn't drop out. longevity testing ongoing.


Review URL: https://chromiumcodereview.appspot.com/12062002
------------------------------------------------------------------------
Jan 24, 2013
#138 dalecur...@chromium.org
Closing this bug since this issue is fixed, will handle merges on  issue 168859 .
Status: Fixed
Mar 10, 2013
#139 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Area-Internals -Feature-Flash -Feature-Media-Audio -Mstone-24 Cr-Internals-Media-Audio Cr-Content-Plugins-Flash Cr-Internals M-24
Apr 5, 2013
#140 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: Cr-Blink
Apr 5, 2013
#141 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Cr-Content-Plugins-Flash Cr-Internals-Plugins-Flash
Jul 24, 2013
#142 lafo...@google.com
(No comment was entered for this change.)
Cc: -jeffr...@chromium.org
Sign in to add a comment

Powered by Google Project Hosting