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

Issue metadata

Status: Fixed
Owner:
Closed: Feb 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression



Sign in to add a comment
link

Issue 170498: Certain audio devices cause irregular OnMoreData callbacks.

Reported by dalecur...@chromium.org, Jan 16 2013 Project Member

Issue description

Noticed this on my home Windows desktop with a Creative Sound Blaster X-Fi Titanium; does not reproduce with a similar machine using an NVidia GTX 680 for audio playback over HDMI.

The trace shows that every once in a while two OnMoreData calls are issued back to back. I've disabled audio output resampler, so the calls are coming directly from the output stream. Due to our non-blocking shared memory this leads to pops and clicks. :(

crogers suspects this is because the callbacks are happening every 11.9ms instead of every 10ms which leads to an underflow requiring WASAPI to issue an additional data callback.
 

Comment 1 by dalecur...@chromium.org, Jan 16 2013

This issue is a regression since we removed the blocking shared memory for WASAPI. Depending on wide spread this is, we may need to consider putting that back.

To be honest, I'm beginning to feel like non-blocking shared memory is causing far more trouble than it's worth. A syn/ack solution using SyncSocket for all platforms would alleviate the sleep issues at little cost.

Comment 2 by dalecur...@chromium.org, Jan 16 2013

Trace attached.
wasapi-no-aor.zip
2.3 MB Download

Comment 3 by henrika@chromium.org, Jan 17 2013

"To be honest, I'm beginning to feel like non-blocking shared memory is causing far more trouble than it's worth. A syn/ack solution using SyncSocket for all platforms would alleviate the sleep issues at little cost."

I assume that https://codereview.chromium.org/11975031/ is step in this direction; right.

Can you compare using different sample rates? I have done changes lately for the unified audio backend where I've improved how an internal buffer size is derived. It can lead to more stable performance for the 44.1 case. Assuming that you only see this on 44.1, we could dig some more there as well.

Comment 4 by crogers@google.com, Jan 17 2013

Henrik, it's interesting to examine the trace where it's clear that the WASAPI clock is not happening at regular 10ms intervals, but instead is regular intervals about 11.8 or 11.9ms.  Then it looks like it's "losing" about 1.9ms each callback and thus needs to make up for the lost time every few callbacks where we get a "back-back" callback.  This is easily seen in the trace.

One guess is that this particular device does not like 440 for a buffer-size, and instead prefers 512?  This may be a low-level implementation detail in that driver? The ratio 512/440 is around 1.16 -> 11.6ms??  

Henrik, is there any possibility of that, and if so, how would we query the driver using WASAPI to know the difference.  I suppose we could just run the device for a few cycles and observe this timing, but that seems pretty yucky.

Dale, is there any chance you could hack your build to use 512 instead of 440, and see if that makes any difference?

Comment 5 by henrika@chromium.org, Jan 17 2013

Chris, please note that 440 (or 880 actually) is only used for WebRTC which
does not ask for the native size. For those clients which asks, the size is
given by:

if (mixing_sample_rate % 11025 == 0)    // Use buffer size of
~10.15873 ms.    return (112 * (mixing_sample_rate / 11025));
What I am saying is that there is a more accurate way to derive the
native size. For most devices 448 works well but some wants 447 or
449. It could lead to more clean sequence if the same method to derive
the buffer size as I do in the CoreAudioUtil is used instead.
Just a theory since we don't even know if Dale is running at 44.1.
Dale: which audio client are you using here?

Comment 6 by dalecur...@chromium.org, Jan 17 2013

WebAudio and HTML5 w/ renderer side mixing both exhibit the same issue. I'll try with --audio-buffer-size=512 when I get home today.

Comment 7 by dalecur...@chromium.org, Jan 17 2013

Also, different sample rates made no real difference, all had bad clicking.

Comment 8 by dalecur...@chromium.org, Jan 18 2013

512 resolved my issues with 44.1kHz and 2048 resolved them with 192kHz.  440 and 1920 respectively caused glitching.

Comment 9 by dalecur...@chromium.org, Jan 18 2013

Is there an API to ask windows its preferred buffer size?

Comment 10 by dalecur...@chromium.org, Jan 18 2013

Per http://msdn.microsoft.com/en-us/library/windows/desktop/dd370866.aspx it seems like we should open an endpoint and then call GetBufferSize() to identify the true buffer size. WASAPI seems to only guarantee that it will allocate a buffer of at least as large as the requested one.

Comment 11 by henrika@chromium.org, Jan 18 2013

To access IAudioClient::GetBufferSize() one must go pretty deep in the
stack and I have (so far) tried to use thinner methods to query a suitable
buffer size. Also, if we open up a device and then use the result of a GBS
call, we would get 960 as a result on all 48kHz devices and not 480 as we
do today even if 480 works perfectly. I.e., we would add too much delay.
Please note that GetBufferSize() gives you the maximum capacity of the
output buffer (what we can write in one processing pass) and it is not the
same as the most suitable buffer size the client should provide.

The trick is that our implementation is driven by an internal clock (device
period) which is not the same as what you get from GetBufferSize(). For
48kHz, the device period is 10ms and it fits 20ms perfectly which means
that we can keep a perfect timing by writing 10ms chunks.

Now, for 44.1 kHz, the device period is not 10ms, but e.g. 10.159ms, which
corresponds to 448 audio frames. We can derive this without opening any
device in only a few method calls and given 448, I *know* that
GetBufferSize() will return 448*2=896. I don't have to ask. Hence, feeding
448 per callback will match the buffer perfectly and we are fine.

Other devices can have 10ms as device period for 44.1kHz which means that
441 is the size we shold use and it will lead to 882 from GetBufferSize().

As I've mentioned earlier, we don't deliver a perfect size today in
GetHarwareAudioSize() since we only use look-up and base it on the sample
rate. That is not perfect!

The perfect (best QoS and lowest delay) solution is to do as I now do in
CoreAudioUtil (can't take all the details here). It would give the values
I've discussed above and not 448 for all 44.1 devices as we have today.

Dale, you have a really good point in that we *could* use GetBufferSize()
but: (1) it costs in usage and (2) it will not lead to the lowest possible
delay. But yes, it would most likely be the most robust solution.

I would like to get a second chance here and try to tweak the existing
scheme and let you (Dale) try it out. I state that I can at least come up
with the same estimate as with GetBufferSize() without calling it (hence
identical result in a much simpler way).

Comment 12 by henrika@chromium.org, Jan 18 2013

Cc: -henrika@chromium.org dalecur...@chromium.org
Labels: -Pri-2 -Mstone-24 Pri-1 Mstone-26
Owner: henrika@chromium.org
Status: Assigned

Comment 13 by kjellander@chromium.org, Jan 18 2013

Labels: not-webrtc

Comment 14 by dalecur...@chromium.org, Jan 18 2013

Sounds good Henrik, thanks for the detailed explanation! Depending on how prevalent this is, we may at least have to back-merge the fix to M24. I'm sure I'm not the only one seeing this.

Comment 15 by henrika@chromium.org, Jan 21 2013

Dale; I will provide an initial CL next week. It would be great if you
could try it on your device as well. The fact that there were issues at
192kHz as well makes me a bit worried that my line of reasoning might not
be perfect (a buffer size of 1920 *should* work here if I am correct).
There might be other factors involved here as well and not only the native
audio layer.

Comment 16 by dalecur...@chromium.org, Jan 23 2013

 Issue 171635  has been merged into this issue.

Comment 17 by henrika@chromium.org, Jan 24 2013

Status: Started

Comment 18 by ultragre...@gmail.com, Jan 31 2013

I have this problem with HTML5 audio and Sound Blaster Xifi too since version 24.
Sound distorted during watching a HTML5 video.

If you want some tests, tell me.

Comment 19 by jszilva...@gmail.com, Feb 2 2013

I came here after reading through  issue 161307 .
I'm using a SB Audigy and experiencing the same symptoms as described in this thread. I have tried changing the version of Flash being used as described in  issue 161307  but the clicking in the audio continues.

I would like to try increasing the buffer to 512 to confirm if the issue I'm experiencing with my card is the same as the issue described in this thread. Is there another thread that provides instructions for making the increase from 440 to 512?

I'm happy to provide more details (rdio and youtube are both affected) if you would like.

Comment 20 by henrika@chromium.org, Feb 2 2013

jszilvagyi@: We are working on a proper fix for the issues that you
describe. I am expecting it to land in Canary early next week. Stay tuned
and please report back if it solves your problems once landed. I can't say
for sure if/when the patch will be merged to M24 or other revisions.

Comment 21 by white.ph...@gmail.com, Feb 4 2013

What's strange is this audio issue only occurs for me on Chrome and Canary but not chromium. Youtube videos play fine, but many other sites (like bandcamp) have the stuttering audio. 512 audio buffer size resolves it for me.

Using an X-Fi Titanium Fatal1ty Pro on Windows 7 X64, latest chrome, chromium, and canary installed. I even tried updating the flash plugin on chrome to beta 11.6

@jszilva: Just right click your chrome shortcut, go to properties, "shortcut" tab, edit the "Targer:" field and paste --audio-buffer-size=512 at the end of it so for example it looks like "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --audio-buffer-size=512

Comment 22 by ultragre...@gmail.com, Feb 4 2013

I have the problem with youtube video. But only with html5, with flash it is ok.

Comment 23 by jszilva...@gmail.com, Feb 4 2013

I added "--audio-buffer-size=512" to my shortcut and am happy to report that it also resolved the sound issue with my SB Audigy. Good catch on that one guys. I'm looking forward to the update that applies the permanent fix. (thanks to Henr in particular for the instructions).

Comment 24 by ultragre...@gmail.com, Feb 4 2013

and for me the --audio-buffer-size=512 option dont fix anything...

Comment 25 by dalecur...@chromium.org, Feb 4 2013

@UltraGreg what sample rate are you using? If you're using 192kHz you might try --audio-buffer-size=2048.

Comment 26 by ultragre...@gmail.com, Feb 4 2013

24 bits / 48000 Hz

Comment 27 by dalecur...@chromium.org, Feb 4 2013

Hmm, not sure then.  henrika has a fix that will go out to canary in a couple days; once that lands hopefully it will resolve your problem.

Comment 28 by ultragre...@gmail.com, Feb 4 2013

I try :
24 bits/44100Hz & Buffer to 512 --> OK

24 bits/48000Hz & Buffer to 512 --> KO
24 bits/48000Hz & Buffer to 1024 --> KO
24 bits/48000Hz & Buffer to 2048 --> OK

24 bits/96000Hz & Buffer to 2048 --> OK

Comment 29 Deleted

Comment 30 by ultragre...@gmail.com, Feb 4 2013

But now with 24 bits/48000Hz & Buffer to 2048, I have a very little distorsion on flash video which I did not have without buffer...
And HTML5 videos are perfect now.

So I think there is a difference between flash audio and HTML5 audio...

Comment 31 by bugdroid1@chromium.org, Feb 6 2013

Project Member
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=180936

------------------------------------------------------------------------
r180936 | henrika@chromium.org | 2013-02-06T08:41:24.221251Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/win/core_audio_util_win_unittest.cc?r1=180936&r2=180935&pathrev=180936
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/win/audio_unified_win.h?r1=180936&r2=180935&pathrev=180936
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/win/core_audio_util_win.cc?r1=180936&r2=180935&pathrev=180936
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/win/core_audio_util_win.h?r1=180936&r2=180935&pathrev=180936
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/renderer/media/webrtc_audio_device_unittest.cc?r1=180936&r2=180935&pathrev=180936
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/win/audio_low_latency_output_win_unittest.cc?r1=180936&r2=180935&pathrev=180936
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/renderer/media/webrtc_audio_capturer.cc?r1=180936&r2=180935&pathrev=180936
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/win/audio_low_latency_output_win.cc?r1=180936&r2=180935&pathrev=180936
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/renderer/media/webrtc_audio_renderer.cc?r1=180936&r2=180935&pathrev=180936
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/win/audio_low_latency_output_win.h?r1=180936&r2=180935&pathrev=180936
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/renderer/media/webrtc_audio_renderer.h?r1=180936&r2=180935&pathrev=180936
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/audio_util.cc?r1=180936&r2=180935&pathrev=180936
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/win/audio_unified_win.cc?r1=180936&r2=180935&pathrev=180936

Avoids irregular OnMoreData callbacks on Windows using Core Audio.

Browser changes:

- Improves how native audio buffer sizes are derived on Windows.
- Forces user to always open up at native audio paramters.
- Improved internal scheme to set up the actial endpoint buffer based on input size.
- Refactored WSAPI output implementation and introduced CoreAudioUtil methods.
- Harmonized WSAPI output implementation with exusting unified implementation (to prepare for future merge).
- Changed GetAudioHardwareBufferSize() in audio_util.

Render changes for WebRTC:

- WebRTC now always asks for an output stream using native parameters to avoid rebuffering in the audio converter.
- Any buffer-size mismatch is now taken care of in WebRtcAudioRendrer using a pull FIFO. Delay estimates are also compensated if FIFO is used.
- Added DCHECKs to verify that methods are called on the expected threads.

BUG= 170498 

TEST=media_unittests, content_unittests, HTML5 audio tests in Chrome, WebAudio and Flash tests in Chrome, WebRTC tests in Chrome.

Review URL: https://codereview.chromium.org/12049070
------------------------------------------------------------------------

Comment 32 by henrika@chromium.org, Feb 7 2013

Status: Fixed
A patch should now exist in latest Chrome Canary (just in case, please check the revision number in chrome:\\version and verify that it is higher than 180936).

It would be great if all users who have experienced audio glitches on Windows could try out the new version and report back.

Thanks.

Comment 33 by henrika@chromium.org, Feb 7 2013

Cc: kjellander@chromium.org elham@chromium.org
 Issue 166524  has been merged into this issue.

Comment 34 by ultragre...@gmail.com, Feb 7 2013

I begin to test Canary (181233).
With Flash Video, I don't hear glitches or distorsion, same as before.
With HMTL5 Video, I have heard some glitches, but it seems to be less as before. I continue test.
But there is now another problem. I can't play a HTML5 video until the end ! Video STOPS before the end, and does not restart. It'is not a connection problem.
With some Flash Video, Video goes to the end, but there is no sound after a time, just the video.

I will continue to test

Comment 35 by henrika@chromium.org, Feb 7 2013

@ultragreg24: this patch should not have any effect on video and I am unable to comment on that part now. Can you explain when you hear glitches; all the time, at a certain rate etc.? Also, what audio device are you using and what sample rate + channel config?

What happens if you simply play a wav-file (e.g. http://www.nch.com.au/acm/11k16bitpcm.wav or any other similar example); do you hear glitches then as well?

Comment 36 by ultragre...@gmail.com, Feb 7 2013

I don't have glitches all the time. When I have one, if I replay, I don't hear it. It is really less as before. Definitely less disturbing if it is only once by play.
But I can't listen a HTML5 audio/video to the end...

So I test just audio, and symptoms are the sames ! I need sample more the 3-4 min to have a problem, with short samples it works without problem.
With a 4 min HTML5 audio (taken here http://blog.gingertech.net/wp-content/uploads/2011/01/LCA_MM_AVProc2011/#slide3), music stop after 3 min, cursor does not move anymore.
With a flash audio (taken here http://refx.com/products/nexus/expansions/) (I think it is flash), audio stop after randomly after 2-3 min, and cursor always moves.

With or without Video, it is for me the same thing.

Current config :
Windows 7 / 4GB RAM
Creative SB X-Fi 6.0.1.1375
Canal 2, 24 bits, 48000Hz

Comment 37 by ultragre...@gmail.com, Feb 7 2013

For glitches, it may be due to a connection problem now, if it is not all the time, just sometimes, and don't happen again if I replay.
I could confirm after a few days of listening.

Comment 38 by dalecur...@chromium.org, Feb 7 2013

Status: Assigned
henrika: We've got another report of the same random stoppage from "harmony.claire" on  issue 165305 .  I'll test on my X-Fi setup at home as well, but I suspect we've still got problems.

Comment 39 by dalecur...@chromium.org, Feb 8 2013

Hmm, I was able to repro once, but haven't been able to since. I'll keep sawbuck running and let you know if I get any error messages out of it.

If it helps: I was watching a flash video at the time and playback stopped while the youtube time slider kept advancing.  HTML5 videos wouldn't even advance until I restarted the browser, which suggests callbacks weren't even occurring.

Comment 40 by henrika@chromium.org, Feb 8 2013

Trying to land https://codereview.chromium.org/12220076/ today to take care of the reported "audio can stop playing" issue.

Dale, as mentioned separately, I did experience bad audio on Windows on TOT using <audio> and building for Debug. We have also seen spdy issues today and it could be related to a spinning IO; not sure actually. Anyhow, WebRTC and WebAudio sounds perfect. <audio> is fine in Release. Please check that if possible.

Comment 41 by bugdroid1@chromium.org, Feb 8 2013

Project Member
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=181527

------------------------------------------------------------------------
r181527 | henrika@chromium.org | 2013-02-08T18:28:45.323214Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/win/audio_low_latency_output_win.h?r1=181527&r2=181526&pathrev=181527
   M http://src.chromium.org/viewvc/chrome/trunk/src/media/audio/win/audio_low_latency_output_win.cc?r1=181527&r2=181526&pathrev=181527

Ensures that WASAPI audio output does not go silent in rare cases

BUG= 170498 
TEST=youtube, <audio> tests and content_unittests

Review URL: https://chromiumcodereview.appspot.com/12220076
------------------------------------------------------------------------

Comment 42 by henrika@chromium.org, Feb 11 2013

@ultragreg24: please try Canary again. Should be fixed now.

Comment 43 by ultragre...@gmail.com, Feb 11 2013

Ok, no more problem of audio stoppage.

So now I can listen completly tracks. And I'm sorry, but I still have glitches with HTML5 audio.
I have glitches at less twice by track, everytime, but not at the same points if I replay the track. The 2/3 Glitches have an interval of 10-11s each, and the rest of the track is perfect. This is often at the beginning of the track (in the first 2 min).

Flash audio is perfect.

Comment 44 by crogers@google.com, Feb 11 2013

ultragreg24: would you mind trying a WebAudio example playing a steady tone (more or less):
http://chromium.googlecode.com/svn/trunk/samples/audio/oscillator.html

so we can know if the glitches happen there.  If it's only happening in <audio>, it may indicate a buffering problem...

thanks!

Comment 45 by ultragre...@gmail.com, Feb 11 2013

Yes I have glitches in WebAudio too with the same conditions.
2 or 3 glitches, with 10-11s intervals each, never at same moment if replaying/refreshing.
perhaps just happen a little bit later than <audio>.

Comment 46 by crogers@google.com, Feb 12 2013

Do you still have the same problems if you explicitly set to 512?
--audio-buffer-size=512

Comment 47 by ultragre...@gmail.com, Feb 12 2013

I have something else I want to notice : since the last update of canary, Chrome has crashed 2 times after playing html5 video.
Before the crash, sound did not stop, but video had big freezes, like 1 image/seconde.

That did not happen usually.

I will tell you if that happens again. I don't know if it could be an effect of previously changes or not...

Comment 48 by ultragre...@gmail.com, Feb 12 2013

Sound is totally chopped, inaudible with --audio-buffer-size=512, html5 or flash is the same thing.

Comment 49 by dalecur...@chromium.org, Feb 12 2013

@ultragreg24: Can you provide a crash id for those crashes from chrome://crashes? 

The --audio-buffer-size flag won't work with the new WASAPI path henrik has right now.

Comment 50 by ultragre...@gmail.com, Feb 12 2013

The chrash report was not active :(
Not possible to send them after enabling the option ?

Comment 51 by dalecur...@chromium.org, Feb 12 2013

No, if you opted out of enabling crash reporting, we'll have to wait until you run into the crash again.

Comment 52 by ultragre...@gmail.com, Feb 12 2013

ok, I will try again tomorrow. It's too late for me now for more tests :)

Comment 53 by dalecur...@chromium.org, Feb 12 2013

No drop outs, crashes, or odd logs on my home system under normal conditions.  I can make the audio drop out temporarily if I spin up an instance of http://www.fossiltoys.com/cpuload.html per cpu core and put the audio tab in the background.

Users with older hardware might have glitching issues with HD video playback until GPU decode support works in Flash on all platforms.

In any case, that's another issue. Depending on what ultragreg reports, we can close this one.

@ultragreg: what does your cpu usage look like during playback glitches?

Comment 54 by ultragre...@gmail.com, Feb 12 2013

No CPU peak when glitches happen. My CPU is around 15% usage.
I have a Quad Core Q9450 @2,6GHz.

When crashes occur, no cpu peak too.
I try tonight to run into the crash again.

Comment 55 by ultragre...@gmail.com, Feb 12 2013

I have too 1GB of free RAM durung the playing.

Comment 56 by aechow.w...@gmail.com, Feb 12 2013

Cc: josewong...@gmail.com jeffreyc@chromium.org anthony....@adobe.com brettw@chromium.org scherkus@chromium.org viettrungluu@chromium.org alberto@chromium.org jtlinden@chromium.org dedr...@adobe.com
 Issue 175249  has been merged into this issue.

Comment 57 by aechow.w...@gmail.com, Feb 12 2013

 Issue 175249  has been merged into this issue.

Comment 58 by henrika@chromium.org, Feb 18 2013

Dale: I propose that we mark this one as fixed.

Comment 59 by ultragre...@gmail.com, Feb 18 2013

So what about glitches on html5 audio and webaudio ? 
You create a new one ? and wait other feedbacks ?

Comment 60 by henrika@chromium.org, Feb 18 2013

Cc: msrchandra@chromium.org
 Issue 171088  has been merged into this issue.

Comment 61 by henrika@chromium.org, Feb 18 2013

ultrareg24@: we have received several reports that the latest fixes as solved the problem on many different devices including your particular device. To me it seems like your environment is an outlier and I don't have any really good things to try out to help you at the moment. Can you try using a USB headset and see if you can repro that way? Not sure if it has been mentioned but have you tried all supported sample rates on the Sound Blaster card? Can you perhaps try on another machine using the same audio card?

You are of course free to report a separate issue for your particular problem.

Comment 62 by ultragre...@gmail.com, Feb 18 2013

I don't have USB headset. And I can't currently test with another machine the same card.
Different rates has been tested, with the same effects.
With IE9 no problems with HTML5 audio.

I think since the beginning I don't have the same issue like the others, because for me flash has worked well all the time.
So you can close this one if you want, I will create another report for my specific problem.
And I think, there is not a lot of html5 audio listener, so not a lot of people can reproduce it yet...

Comment 63 by henrika@chromium.org, Feb 18 2013

Status: Fixed

Comment 64 by nawoa.la...@gmail.com, Feb 20 2013

Hi, I have an X-Fi card and wanted to provide verification that installing Canary has solved my issue.

Thanks

Comment 65 by Deleted ...@, Feb 20 2013

I as well have an X-Fi card and confirm that Canary no longer reproduces the issue as well.

Thanks

Comment 66 by loma...@gmail.com, Mar 9 2013

Is this supposed to be working in the latest version of Chrome now? Because it doesn't.

Comment 67 by henrika@chromium.org, Mar 9 2013

Chrome Canary should work yes. If you experience problems, please provide
details.

Comment 68 by bugdroid1@chromium.org, Mar 9 2013

Project Member
Labels: -Type-Regression -Area-WebKit -Feature-Media-Audio -Mstone-26 Cr-Content Type-Bug-Regression Cr-Internals-Media-Audio M-26

Comment 69 by Deleted ...@, Mar 28 2013

I have the X-Fi titanium and the 
--audio-buffer-size=512
fixes my issue. Thanks

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

Project Member
Labels: -Cr-Content Cr-Blink

Comment 71 by laforge@google.com, Jul 24 2013

Cc: -jeffreyc@chromium.org

Comment 72 by dalecur...@chromium.org, Aug 8 2015

Hi everyone, I've recently changed some of the code involved in this bug fix. I've verified that my X-Fi card at home on Windows 10 still works correctly, but could use your help with further verification.

If anyone is still following along here, if you could try Chrome Canary 46.0.2476.0 or higher to see if you still have glitch free audio on Windows 7, 8, or 10 that'd be very helpful.

Thanks in advance!

Comment 73 by Deleted ...@, Aug 14 2015

Hey Dale.

I only got this issue on Windows 10. When I upgraded I now have to change my sample rate from 192khz to 44.1khz for chrome to run videos & audio correctly, weirdly enough chrome only has this issue, no other program. I have tried adding --audio-buffer-size=512 in the shortcut settings but it did not work. (Windows 10 & M-Audio Profire 610 Audio Interface).

Comment 74 by dalecur...@chromium.org, Aug 14 2015

deluxnz: What version of Chrome are you seeing this with? I forgot to mention it with my original comment, but the bug I fixed is  issue 516196  which sounds like what you're describing. I think that fix has only rolled to dev-channel and canary thus far, beta and stable will update soon.

Comment 75 by Deleted ...@, Aug 15 2015

Hey Dale.

I am running Version 44.0.2403.155 m.

I reviewed  issue 516196  and --force-wave-audio seemed to fix the issue.

Sign in to add a comment