New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 157613 link

Starred by 117 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: Fixed
Owner:
Closed: Jan 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug



Sign in to add a comment

Microphone input is heavily distorted on numerous mic tests with Pepper

Project Member Reported by nhu...@adobe.com, Oct 24 2012

Issue description


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.
 
Showing comments 43 - 142 of 142 Older

Comment 43 by xians@chromium.org, Nov 15 2012

Owner: dalecur...@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.

Comment 44 by Deleted ...@, Nov 15 2012

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???

Comment 45 by will2...@gmail.com, Nov 15 2012

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! 
Does anyone have working code for getUserMedia({audio:true},function(stream) { /* get stream.audioTracks as buffer, byte array, or anything? */ });



You should enable 'Web Audio Input' under chrome://flags to make it work.
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 :)  
Did you enable Web Audio Input in chrome://flags and restarted chrome?
Project Member

Comment 51 by bugdroid1@chromium.org, Nov 16 2012

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
------------------------------------------------------------------------
What about the acoustic echo issue that has been plaguing us for several months now? http://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.
@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.

@jus .. great .. I tried it now and it works for me too .. hope to see the pepper issue in the stable chrome ASAP.
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. 


comment #50 is related to comment #46,47,48,49
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
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

Comment 59 by will2...@gmail.com, Nov 19 2012

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.
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.

Comment 61 by will2...@gmail.com, Nov 19 2012

I'm still experiencing this issue running Flash Version 11.5.502.110 and Canary 25.0.1329.0 on Mac. Thanks
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.

Comment 63 by Deleted ...@, Nov 20 2012

Hi any update on this bug?
When can the fix be landed on Production Chrome 23?

Thanks

Comment 64 by Deleted ...@, Nov 20 2012

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. 

Comment 65 by Deleted ...@, Nov 20 2012

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.
Our users are also complaining .. We chose chrome for it's consistency and fast updates .. not the case here.
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.

Comment 68 Deleted

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

Comment 70 by Deleted ...@, Nov 21 2012

I agree with the concerns expressed. This is a serious issue that I request be addressed immediately.

Comment 71 by will2...@gmail.com, Nov 21 2012

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.

Comment 72 by Deleted ...@, Nov 22 2012

I agree. The impact will be big from having this fixed!

Comment 73 by will2...@gmail.com, Nov 23 2012

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!
Cc: engedy@chromium.org
 Issue 158974  has been merged into this issue.
 Issue 159888  has been merged into this issue.
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?

Comment 77 by sail@chromium.org, Nov 26 2012

> 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.

Comment 78 by sail@chromium.org, Nov 26 2012

Owner: viettrungluu@chromium.org
Dale says that he's waiting for Trung to update the Flash build.

Comment 79 by Deleted ...@, Nov 27 2012

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!!

Comment 80 by oron...@gmail.com, Nov 27 2012

I concur, meanwhile we have to recommend users on other browsers. 
It's a pity!
Hi,

Why does Google Chrome not fix this? 

Comment 82 by will2...@gmail.com, Nov 27 2012

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!
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!

Comment 84 Deleted

Comment 85 by Deleted ...@, Nov 29 2012

we're also seeing lots of user complaints about this.  Please fix soon. :-(
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 :)
Status: Fixed
I believe this should generally be fixed on the current Canary. We'll ponder merging it to the M23 update.

Comment 88 by will2...@gmail.com, Nov 29 2012

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.
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.

Comment 90 by will2...@gmail.com, Nov 29 2012

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.

Comment 91 by v...@powhow.com, Nov 29 2012

Second that last comment re merging to M23!
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!
@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.

Comment 94 by dfe...@gmail.com, Nov 29 2012

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.
Please merge this into M23, Our site is seriously being affected by this bug!

Comment 96 by ffdi...@gmail.com, Nov 29 2012

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.

Comment 97 by Deleted ...@, Nov 30 2012

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
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

Comment 99 by kareng@google.com, Nov 30 2012

Labels: Merge-Approved
approved for m23. pls change to m24 and requested once it's merged.
Labels: -Mstone-23 Mstone-24
Labels: -Merge-Approved Merge-Requested
@dharani, okay to merge m24?
Project Member

Comment 102 by bugdroid1@chromium.org, Nov 30 2012

Labels: merge-merged-1271
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-Requested Merge-Approved
Project Member

Comment 104 by bugdroid1@chromium.org, Dec 3 2012

Labels: -Merge-Approved merge-merged-1312
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
------------------------------------------------------------------------
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. 
I believe we will have an M23 Stable update in the next week or so.
Status: Assigned
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. 

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

Project Member

Comment 109 by bugdroid1@chromium.org, Dec 7 2012

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
------------------------------------------------------------------------
Project Member

Comment 110 by bugdroid1@chromium.org, Dec 7 2012

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
------------------------------------------------------------------------
Project Member

Comment 111 by bugdroid1@chromium.org, Dec 7 2012

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
------------------------------------------------------------------------
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.
Labels: -merge-merged-1312 Merge-Approved
Approved r171701 for M24 branch.
Is there a target date for m24 to go to prod?
We're soaking the change in M24 before merging to M23.
Project Member

Comment 116 by bugdroid1@chromium.org, Dec 10 2012

Labels: -Merge-Approved merge-merged-1312
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
------------------------------------------------------------------------
Project Member

Comment 117 by bugdroid1@chromium.org, Dec 11 2012

Labels: merge-merged-1271_97
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
------------------------------------------------------------------------
Cc: nyerramilli@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

just to add -- tested on Macbook pro (OS 10.8.2)

Comment 120 Deleted

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.







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''.
Second Rok's comment, several users still reporting problems with distorted sound, all using the Pepper plugin.


Comment 124 by Deleted ...@, Dec 17 2012

Tested on production chrome ver. 23.0.1271.97 @ Mac 13" OSx.
Works fine.


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?




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.

Comment 127 by Deleted ...@, Dec 19 2012

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.
Owner: 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.
Does the issue with OSX dropping audio occur on other flash audio? Try http://tinychat.com - It may be a codec issue perhaps?
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 :)
@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?
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!

Comment 133 by an...@tokbox.com, Jan 8 2013

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
I have reported the audio dropping issues in a new ticket.

http://code.google.com/p/chromium/issues/detail?id=168859
Labels: not-speechapi

Comment 136 by deng...@gmail.com, Jan 22 2013

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. 
Project Member

Comment 137 by bugdroid1@chromium.org, Jan 24 2013

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
------------------------------------------------------------------------
Status: Fixed
Closing this bug since this issue is fixed, will handle merges on  issue 168859 .
Project Member

Comment 139 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals -Feature-Flash -Feature-Media-Audio -Mstone-24 Cr-Internals-Media-Audio Cr-Content-Plugins-Flash Cr-Internals M-24
Project Member

Comment 140 by bugdroid1@chromium.org, Apr 5 2013

Labels: Cr-Blink
Project Member

Comment 141 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content-Plugins-Flash Cr-Internals-Plugins-Flash
Cc: -jeffreyc@chromium.org
Showing comments 43 - 142 of 142 Older

Sign in to add a comment