Maybe it's ubuntu bug?

I don't know. Other browsers work well. Though, they are using flash 11.1.

If this is ubuntu bug, do you think I should file it on their bugtracker?

I've encountered the same thing (coincidentally, or not, after also having installed libssl0.9.8 in an attempt to resolve  Issue 116238 ).

HTML5 media is not affected. I didn't have an opportunity to check animated GIF's rate prior to a reboot apparently fixing the 2x speed problem. 

I'll post again here if the problem reoccurs.  

Sorry:

Chrome 19.0.1055.1 dev
Ubuntu 12.04 (x64)

Yes, it has been fixed by reboot.

Sorry for not checking that.

This has happened again. Reboot is apparently not a permanent fix. 

Seeing the same thing here, reboot doesn't matter.

Chrome 19.0.1055.1 dev
Ubuntu 12.04 (x64)

I'm also seeing this after the latest Ubuntu roll of Chrome dev. Sometimes (but not always) flash videos will play at ~2x rate. I've seen this on YouTube and TED videos. Seeking around the video seems to fix the playback rate issue, but restarting did not fix it for me.

Ubuntu 11.10 (x64)
Chrome 19.0.1055.1 dev, Linux.
Flash (2 files) - Version: 11.2.31.109
Shockwave Flash 11.2 r31

Additionally, even when I'm not seeing the ~2x rate (generally immediately after a reboot), video and audio stutters slightly, and full-screening a video frequently fails. 

This also affects flash audio on Google Music. "Rolling in The Deep" is actually pretty good at 2x, but that's another issue.

@11 I've encountered that as well. 

Same here, Debian testing.

19.0.1061.1 dev fixes the problem for me.

19.0.1061.1 also seems to resolve the problem for me as well.

Not 100% sure, but it seems like 19.0.1061.1 fixed this for me as well (at least, this hadn't appeared so far)

The ~2x speed is has reappeared with 19.0.1068.0 dev. 

2x speed still in 19.0.1068.1 dev

archlinux 64bits

Has appeared for me as well in 19.0.1068.1 dev
(X)Ubuntu GNU/Linux 11.10 (x64)

I'm having some lag problems with videos in Youtube too.

After 5 seconds, videos stop playing.

The solution I found was to disable Chrome native Flash Plugin and use only 
adobe flash plugin

Chrome Version : 19.0.1068.1 dev
Chrome Version :	11.2 r202
Local:	/opt/google/chrome/libgcflashplayer.so

Versão:	11.1 r102
Local:	/usr/lib/adobe-flashplugin/libflashplayer.so

Both are NPAPI

I'm still seeing this in 19.0.1084.1 dev. However, dropping back to the Adobe version is now resulting in the blue tint issue because I have an nvidia card. So I'm kind of screwed either way.

~2x speed issue occurring again in Chrome 20.0.1115.1 dev

I confirm this issue on Ubuntu 12.04 and Chrome 20.0.1115.1 dev. 
I have ASUS Xonad DG sound card if this matters.

Also occurs on Version 20.0.1130.1 dev
Kubuntu 12.04

+1 on archlinux 64bits (20.0.1130.1)

I can confirm this also on 64-bit Ubuntu 12.04. Chrome 20.0.1130.1 beta. I've disabled the Ubuntu version of flash, and this resolves the issue. The version of flash that is installed by Ubuntu is: 11.2 r202.

To disable the Ubuntu version:

1. In the address bar: about:plugins
2. Click details
3. Disable on the 11.2 r202 version, Type: NPAPI, /usr/lib/adobe-flashplugin/libflashplayer.so.

NOTE: Only disable it in Chrome if you are using other browsers that will be accessing the Ubuntu Flash. If you're only using Chrome, feel free to uninstall it.

apt-get purge adobe-flashplugin

@29. I can confirm that this fixed it for me. (21.0.1155.2, Ubuntu 12.04)

There are other fixes, like install libvdpau1:

apt-get install libvdpau1

This "should" allow you to use h/w acceleration.

If none of these work, then disable h/w acceleration:

Start playing a video, right click the video -> settings -> Untick hardware acceleration.

This is an issue that Adobe refuses to fix, and not an issue with Ubuntu or any other distribution. Got to love proprietary software... :-\

See here for more info:

http://askubuntu.com/questions/117127/flash-video-appears-blue

Both Flash and HTML5 videos play at double speed using Google Chrome version 20.0.1132.27 beta on 64-bit Ubuntu. This problem doesn't occur with version 18.0.1025.168.

Confirmed for Version 20.0.1132.47. Disabling the plugin /opt/google/chrome/PepperFlash/libpepflashplayer.so (version 11.3.31.109) fixes the issue.

same problem here, on chrome: 20.0.1132.47
ubuntu 12.04
f*ing adobe flash

Same here Ubuntu 12.04, Chrome 20.0.1132.57

Other then for @29, disabling the chrome plugin (v. 11.3.31.115), and enabling the Ubuntu flash plugin (v. 11.2 r202) fixed it for me.

Using 64-bit Ubuntu 12.04 and Google Chrome 21.0.1180.41 beta I get behavior which differs from the suggested fixes here. With only the Ubuntu flash plugin (11.2 r202) enabled audio is choppy and the video appears to be playing at roughly half speed. If only the Chrome plugin (11.3.31.218) is enabled video and audio play at 2x or greater speed. With both plugins enabled I get the behavior of the latter.

Same with Ubuntu 12.04 running chrome 20.0.1132.57. Disabling either plugin does not fix it.

Same issue.  I'm using Ubuntu 12.04 and have Google Chrome Version 21.0.1180.57.  Videos all play at 2x+ (probably more like 4x)  Make Ubuntu much less useful.  I've tried disabling the Chrome Flash plugin (the 11.31 one) but other played choppy.

Same here. Chrome version:21.0.1180.75

Just to add, I'm having the same experience that "heavymet...@gmail.com"  has. And in Ubuntu 12.04 64 bits

Same problem here.
Starts working normally after disabling chrome's flash plugin.

Ubuntu 12.04 32bits
Chrome Version 21.0.1155.2 dev

 Issue 119979  has been merged into this issue.

 Issue 128762  has been merged into this issue.

 Issue 130375  has been merged into this issue.

 Issue 120801  has been merged into this issue.

 Issue 123706  has been merged into this issue.

im using x-fi hd usb soundcard and it crashes completly with pepper flash. audio just hangs after some time

I've found a workaround for this problem on my Ubuntu Precise workstation: disabling message signalled interrupts for the Intel HDA driver. Details at https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1019693/comments/17

Arch 64bit google-chrome 21.0.1180.89-1 pepper flash: maybe a clue from https://wiki.archlinux.org/index.php/Pulseaudio#Equalizer

When I load the equalizer module, flash plays fast (almost 3x speed), when I unload the module, it plays normally. However, if I open "pavucontrol", it only plays fast for a few seconds, then normally.

Also, if I use adobe flash plugin, it doesn't have playback speed problems.

My home computer has been having issues with 21.x, but after the Chrome 22 upgrade this week, it has been working better.

I'm having this issue with 23.0.1271.10 beta on Ubuntu 12.04 (uname -rvp: 3.2.5-gg987 #1 SMP Fri Sep 14 02:36:36 PDT 2012 x86_64). Audio seems more than 2x too fast; more like 10x?

Unable to repro this issue (tested on Ubuntu 10.04 LTS) on  23.0.1271.17 and the latest dev 24.0.1284.2.

@bezengi.....Could you please install the latest chrome, test again and confirm.

Don't have my own machine with Ubuntu right now.

I've checked on the another machine with Ubuntu 12.04 and Chrome 24.0.1284.2 dev. There are two versions of Flash there:

Name:    Shockwave Flash
Description:    Shockwave Flash 11.4 r31
Version:    11.4.31.108
Location:    /opt/google/chrome/PepperFlash/libpepflashplayer.so
Type:    PPAPI (out-of-process)
      Enable

Name:    Shockwave Flash
Version:    11.2 r202
Location:    /usr/lib/flashplugin-installer/libflashplayer.so
Type:    NPAPI
      Disable

With flash 11.4 (by google chrome) being enabled video really plays like 10x faster. After disabling it video with system flash plays well.

The previous version 22.0.1229.92 used flash version 11.4.31.110 and had the same problem.

I've also checked out chromium-browser (Version 23.0.1271.10 Ubuntu 12.04 (158896)) from here: https://launchpad.net/~a-v-shkop/+archive/chromium-dev. That works well (it uses only system flash though).

I'm seeing this.

Ubuntu 12.04 LTS

Chrome Version 23.0.1271.17 beta

Adobe Flash Player (2 files) - Version: 11.4.31.108
Shockwave Flash 11.4 r31

uname -rvp
3.2.5-gg987 #1 SMP Fri Sep 14 02:36:36 PDT 2012 x86_64

It happens consistently on all Flash video.  On one of the videos I was able to reset to normal speed by scrubbing the timeline slider back to the beginning manually.  That only worked once though.  Other videos, no luck.

I've fixed this on my laptop consistently with `sudo pulseaudio -k` ...but
shouldn't have to do that.

Same problem, Mint 64 MATE, Chrome 22.0.1229.94.  Had to do pulseaudio -k; pulseaudio --start to get sound to work properly.

Noticed that when it's playing flash video/audio jittery/fast, if I open Sound Preferences > Application, the Chrome listing flickers, as if it's rapidly adding and removing it.

It could be a coincidence, but I had not noticed the problem since updating to Ubuntu 12.10 BETA. Could be that a newer Chrome version was released at about the same time.

Same problem here.

OS: Ubuntu 12.04 64bit
Chrome: 21.0.1180.79
PepperFlash: 11.3.31.227

Same problem.

Google Chrome	23.0.1271.97 ()
OS	Linux
Flash plugin	11.5.31.5 /opt/google/chrome/PepperFlash/libpepflashplayer.so
--- Crash data ---
Crash Reporting	Enable crash reporting to see crash IDs
For more details	https://support.google.com/chrome/?p=ui_usagestat
--- GPU information ---
--- GPU driver, more information ---
Vendor Id	0x10de
Device Id	0x06eb
Driver vendor	NVIDIA
Driver version	295.40
Driver date	
Pixel shader version	3.30
Vertex shader version	3.30
GL version	3.3
GL_VENDOR	NVIDIA Corporation
GL_RENDERER	Quadro NVS 160M/PCIe/SSE2
GL_VERSION	3.3.0 NVIDIA 295.40

 Issue 152232  has been merged into this issue.

 Issue 128870  has been merged into this issue.

So we now have a bug that's serious enough that 145 people are watching it, it's a regression from previous versions, and open since May last year.

The state of that bug? "Untriaged".

Does anyone at Google actually read bugs any more?

We're looking into it.  There's seems to be something going wrong in the Pulse-Alsa translation layer provided by Pulse.  Using Pulse or Alsa directly resolves the issue as well as restarting Pulse once the issue is encountered.

Older versions of Pulse do not exhibit this problem; it seems to have been introduced somewhere between PulseAudio 0.9.21-63-gd3efa-dirty and 1.1.  If anyone can help narrow this range by reporting version numbers < 1.1 that show the problem (pulseaudio --version) we might be able to trace this to an upstream change.

I'm seeing it on pulseaudio 1.0 (Ubuntu 11.10/oneiric) and Chrome 24.0.1312.52

Specific versions:
  alsa-base                             1.0.24+dfsg-0ubuntu2                     
  alsa-utils                            1.0.24.2-0ubuntu8.1                      
  pulseaudio                            1:1.0-0ubuntu3.1                         
  pulseaudio-esound-compat              1:1.0-0ubuntu3.1                         
  pulseaudio-module-bluetooth           1:1.0-0ubuntu3.1                         
  pulseaudio-module-x11                 1:1.0-0ubuntu3.1                         
  pulseaudio-utils                      1:1.0-0ubuntu3.1        

Actually the command you posted indicates I am using pulseaudio 3.0 and I still exprerience this problem. I am using chromium 24.0.1312.52 (175374) and I only get the issue for flash videos not for html5 videos. Many of the merged issues reported only problems with flash videos. Furthermore, I have 3 machines on Arch linux with the same version of pulseaudio and the only with this issue is the one with NVIDIA hardware (using NVIDIA binary blob).

Should I open another bug ? There seems to be at least one commenter who was also using the NVIDIA binary blob.

Sorry, 1.1 is not an upper bound for the issue, just the most recent version I'd found locally which exhibited the issue.  I suspect your issue is still the same.  Flash just uses a smaller buffer on Linux than HTML5 and is thus more susceptible.

I suspect if you use --enable-renderer-side-mixing you'll see the same problem with HTML5.

I've experienced this with pulseaudio 1.0 and whatever Chrome beta build was right before my current 25.0.1364.36 beta, on Xubuntu 11.10. It's only happened once or twice, but I'll post version number here if it happens again.

I suspect what's happening is that PulseAudio is getting into a state where it wants a massive audio buffer.  Which Chrome unsuccessfully attempts to fill, scheduling callbacks as fast as possible and never exhausting the buffer Pulse wants.

When I hack these conditions in, I can reproduce the 2x+ speed up.  I'm not sure what's causing PulseAudio to ask for such a large buffer or the best way to go about fixing that yet.

I'll see about getting some experiments on canary next week to see if we can at least bandaid over the issue with a rate limiting approach for now.  Long term, we're working towards a native pulse driver which shouldn't have this issue.

I haven't had the issue in a long time. I'm on Pulseaudio 2.1 if that helps.

I'm running Ubuntu 12.10 (I also believe PA 2.1), with 25.x and 26.x revs of Chrome, and no problems at all for some time now.

I'm still having this problem with pulseaudio 1.1 and Chorme 24.0.1312.52, on Ubuntu 12.04.1 LTS. Actually, starting some weeks ago it started happening very often.

As you suspected, using the --enable-renderer-side-mixing switch I can reproduce the problem with html5 videos.

I have some javascript code which seems to reproduce this at will, given the above observations, under pulseaudio 1.1, chrome 24.0.1312.52.

I have an unfinished javascript demo at http://a1k0n.net/code/webkitsynth/ which exhibits this problem on linux if I change the ctx.createJavaScriptNode(2048,0,2) call with a 1024-sample buffer.  2048 samples works fine, 1024 plays double-ish speed, 512 sounds even worse, and I believe the buffer has to be a 2^n size so no intermediate value works.

Use http://www.a1k0n.net/code/webkitsynth/index1024.html for a 1024-sample buffer to reproduce the problem (and even restarting pulseaudio won't help) or just index.html for the 2048-sample buffer which seems to work fine.

It sounds like it might be a bug in Chrome independent of the buffer size pulseaudio is asking for -- just if its own internal callback provides a short write, then it resets the device or something.  Under certain assumptions of the behavior of snd_pcm_writei inside media/audio/linux/alsa_output.cc where RunDataCallback doesn't fill the buffer, this might be slightly plausible.  Or perhaps resetting last_fill_time_ after each RunDataCallback in an effort to avoid back-to-back callbacks is causing the problem -- back-to-back callbacks are necessary to fill the buffer if the underlying callback doesn't write enough data.  I will attempt to build chromium and test these theories.

@asloane: I believe that's a different issue with WebAudio.  For me the 1024 page plays half as fast as the 2048 one, which I suspect means WebAudio is only half filling the 2048 (the hardware buffer size on Linux for Chrome) frame buffer on each callback. I'd file a new bug and cc rtoy, crogers.

That makes more sense; it does sound like half speed rather than double.  Will do, thanks.

Can someone experience the issue try this build Linux X64 build:

http://commondatastorage.googleapis.com/dalecurtis-shared/chrome-alsa-test.tar.bz2

It includes a speculative fix and should print some info about the current buffer size:
[19382:19391:0125/172951:ERROR:alsa_output.cc(258)] Buffer Size: 4096 Period Size: 1024

After extracting the build, launch like:

./chrome --user-data-dir=/tmp/.chrome-data --disk-cache-dir=/tmp/.chrome-cache --ppapi-flash-path=libpepflashplayer.so --no-first-run --enable-dcheck

Please ensure that PPAPI flash is being used by ensuring the NPAPI version is disabled under chrome://plugins.

Once you've got it running try to reproduce the issue and report back. If you still see the problem, please send any console output from Chrome.  Thanks in advance!

I tried with the fix but the video and sound were still playing too fast. I got this from the logs:

[28999:29006:0127/143625:ERROR:alsa_output.cc(258)] Buffer Size: 4096 Period Size: 1024


This issue occurred to every video I tried for both ArchLinux's version of chromium and this test build.

I've been experiencing a curiously similar problem of audio playing too fast while developing a WebAudio music visualization.

I've managed to create a jsfiddle that reproduces the issue every time (on my PC). 

http://jsfiddle.net/gFTUS/ (attached)

Apologies to the html5rocks people for poaching their bandwidth :)

I'm running Ubuntu 12.10 (32-bit). Chrome Version 26.0.1386.0 dev.

For me the problem occurs when all of the following are true:
* I'm running Chrome on Linux.
* The audio element is defined in html and connected via createMediaElementSource.
* An analyser is also connected to the audio source.
* The javascript is located in a <script> tag within the html section of jsfiddle. (I havn't looked into what effect this has).

The following changes prevent the bug from occurring (resulting in correct behaviour):

* Move js into the script area
http://jsfiddle.net/GBfvY/

* Create audio element using document.createElement
http://jsfiddle.net/HL7jd/

* Disconnect analyzer
http://jsfiddle.net/NYkwY/

I can reproduce the problem with a USB headset and with 3.5mm headphones.

Let me know if there is anything else I can do to help.

Best of luck :)

repro.html 734 bytes View Download

@jcharest: Do you get any other alsa or pulse related logs on the console?

@steven: I'm not able to reproduce the issue using that link. I suspect this issue is tied to one's Pulse settings or the hardware they're using.

This was the only line that appeared on the console. It seems to appear once per video I tried. 

@jcharest: Can you try this build:

http://commondatastorage.googleapis.com/dalecurtis-shared/chrome-alsa-test-2.tar.bz2

Launch it the same way, but it's going to be super spammy, so please redirect stderr to a file a la:

./chrome --user-data-dir=/tmp/.chrome-data --disk-cache-dir=/tmp/.chrome-cache --ppapi-flash-path=libpepflashplayer.so --no-first-run --enable-dcheck 2> chrome-stderr.log

Please reproduce the issue than upload the log to issue tracker (there should be an attach file button in the reply section).

Thanks!

I always have this problem, and it usually happens when memory load is high, about 85%+, then the speed of flash player is at about 2x suddenly.

Tested with new build, same result but that was expected I guess. Here is the log

chrome-stderr.log 424 KB View Download

@jcharest: Thanks. I put together a fix modeled on that log, but it may introduce glitching and/or higher cpu usage.  Can you try this build:

http://commondatastorage.googleapis.com/dalecurtis-shared/chrome-alsa-test-3.tar.bz2

(Execute the same as last time, with stderr redirected, as it's still spammy).

Please try a YouTube video as well as some HTML5 and WebAudio demos:
http://commondatastorage.googleapis.com/dalecurtis-shared/buck2.webm
http://chromium.googlecode.com/svn/trunk/samples/audio/shiny-drum-machine.html

Thanks!

So the video seemed at the right speed but I could still only hear clicks in the audio. The clicks were not occurring as fast though. Here are the logs.

This comment applies to youtube flash video, HTML5 video and audio.

chrome-stderr.log 853 KB View Download

@jcharest: You said "[you] could still only hear clicks in the audio." Does that mean you have no audio but a constant clicking? Or that you have normal audio with clicking in it? Also does restarting PulseAudio help you? (i.e. pulseaudio -k)

For any PulseAudio experts out there, the log from #93 shows:
1. Pulse indicating it has space for 4096 frames of audio (~93ms @ 44.1kHz).
2. Chrome filling 2048 frames immediately.
3. Chrome observing there are 2048 frames remaining and filling another 2048 frames 5ms later.
4. ~38ms later, Pulse indicating it has 4096 frames of audio available again.
5. Repeat from #2.

From Chrome's perspective, the problem is Pulse claiming it has ~93ms available again when only ~43ms of real time has expired, and thus it should only have ~2048 frames available.

I mean no audio but a constant clicking. I will try restarting pulseaudio later today.

@jcharest: Ah not good. Okay I have another speculative fix here:

http://commondatastorage.googleapis.com/dalecurtis-shared/chrome-alsa-test-4.tar.bz2

Same drill as before. Thanks!

I restarted pulseaudio just before testing.

So, this build does improve the playback to some extent so the fix seems to have a positive effect. I now can hear audio but it skips enough that I cannot understand any words.

chrome-stderr.log 872 KB View Download

Nice! Now we're getting somewhere, the log shows Pulse isn't expiring the buffer spuriously now, but we're waiting too long to fill it.  How about this one:

http://commondatastorage.googleapis.com/dalecurtis-shared/chrome-alsa-test-5.tar.bz2

Great, this is even better: I can understand words in the video but it is going a bit too fast.

chrome-stderr.log 1.0 MB View Download

Hmm, sadly that log shows we're back to the original problem where Pulse magically has an empty buffer again; this time we go from 0 frames available to 4096 in the space of 5ms...

Here's another one with a bit more logging:

http://commondatastorage.googleapis.com/dalecurtis-shared/chrome-alsa-test-6.tar.bz2

Here are the new logs. Same result as build 5.

chrome-stderr.log 430 KB View Download

Interesting, that log shows the pcm state cycling between 3 (SND_PCM_STATE_RUNNING) and 2 (SND_PCM_STATE_PREPARED).  I don't think that's normal.  Perhaps I can key off that state to make a determination of how ready Pulse actually is. I'll make another build tomorrow.  Thanks again for your help jcharest!

Just more logs this time:

http://commondatastorage.googleapis.com/dalecurtis-shared/chrome-alsa-test-7.tar.bz2

Plus an additional Q: If you go to Sound Settings in Ubuntu (search Sound or click settings from the speaker icon in the bar).  Are any of the devices quickly disappearing and reappearing?  We've seen a bug on audio input where the output device appears to be constantly restarted.

Here is the log. 

I use Archlinux with gnome3 but I believe it must be the same sound setting app as in Ubuntu (gnome-control-center sound). I have not seen any flickering of the devices in the sound setting app. Also I have no audio problem other than this issue.

chrome-stderr.log 1014 KB View Download

Thanks for the log, I found someone internal with the same problem too.  The reason for the glitching is ALSA is returning with "snd_pcm_avail() failed: Broken pipe" we then issue a snd_pcm_recover() which probably destroys the current playback buffer.

Digging to find out why this might be the case.

@jcharest: If you run "pactl exit" and "ps -ef | grep pulse" before and after only shows a new Pulse process, do you still have the glitching issue?

If you can still reproduce the issue, can you send me the logs from running "pulseaudio -vvvv 2> pulse-stderr.log" and the last chrome build?  the pulse command will only work if no other pulse processes are running, so you'll need to run the "pactl exit" first.

If it's working, the process should block. Thanks.

@jcharest: Also, one more test build which counter-intuitively lowers the buffer size Chrome wants from 2048 to 512:

http://commondatastorage.googleapis.com/dalecurtis-shared/chrome-alsa-test-9.tar.bz2

Without pulseaudio logs is fine for this test build.

reply to comment#108
1 - I can reproduce when restarting pulse. See first attachment (using script to log so you can see the commands I did).
2 - See other attachment for a pulseaudio log. (also using script)

reply to comment#109
1 - Video seems at the right speed but I hear no audio (silence), I am seeing lots of: 
pcm_avail_update() failed: Broken pipe. 

See the last attachment for that log.

build7_pa_vvvverbose.log 0 bytes Download

build9.log 3.4 MB View Download

build7_restartpa.log 0 bytes Download

Oups... I deleted the two first logs before submitting but after attaching... I will get them again (rm as no trash).

Here they are.

build7_restart_pa.log 547 KB View Download

build7_pa_vvvverbose.log 1.2 MB View Download

I notice in your log you have "tsched=no", have you tried the tsched=1 fix mentioned in  issue 108396 ? E.g.; Modify /etc/pulse/default.pa so the line "load-module module-udev-detect" is now "load-module module-udev-detect tsched=1" ?

Oh, that fixed the issue.

I think I actually changed that some time ago (I had forgotten about it though) following instructions on this page due to crackling in Skype:
https://wiki.archlinux.org/index.php/PulseAudio#Glitches.2C_skips_or_crackling

So I guess this issue is a duplicate of 108396 (at least for me). Do others that posted here have timer based scheduling disabled ?

P.S. I am really sorry to have taken your time for this.

@jcharest: No problem. I'm glad that worked for you!

Is there anyone else on this bug who is still having problems even when tsched=yes?

Ping. There are 121 people starred on this bug, hopefully someone is out there :) Does  anyone still has problems even with tsched=yes?  Otherwise I'll mark this bug as a duplicate of  issue 108396  and consider the issue closed.

To be clear, requiring a kernel parameter to fix a regression in a userspace application (Chrome) caused by the introduction of Pepper is by no stretch of the imagination a fix to this problem.

Quite apart from the whole regression aspect, please bear in mind that the user of Chrome on the box may not have root access. 

It is however, an interesting datapoint in debugging. I went back to Ubuntu's Chromium build a long time ago as it's much more stable than Chrome, but I'll see if I can reinstall and recreate.

@mbligh: As far as I know these changes can be made to the user specific config as well: http://linux.die.net/man/5/default.pa, no root access necessary.

If you get a chance please try the following test build and report the logs back as detailed in comment #91.

http://commondatastorage.googleapis.com/dalecurtis-shared/chrome-alsa-test-7.tar.bz2

Thanks!

OK, fair enough - will try. Curious what the underlying issue is though.

 Issue 175339  has been merged into this issue.

 Issue 175339  has been merged into this issue.

@dalecurtis: I'm running 32bit Ubuntu - have you got a 32-bit test build I could try? I tried the 'tsched=yes' workaround but it had no effect.

@steven: Not at the moment. Did you run "killall pulseaudio" while Chrome was not running and wait until audio came back (watch your sound tray icon in Ubuntu) before starting chrome again?

 Issue 175339  has been merged into this issue.

dalecurtis: Yep - I did as you said. I can reproduce the problems using different audio devices. Please find attached my pactl output and pulse logs for analog and digital outputs when running HTML5 audio in Chrome. Hopefully there is some commonality between them that will pin down the issue.

To generate the pulse logs I used:

echo autospawn = no >> ~/.pulse/client.conf
killall pulseaudio
LANG=C pulseaudio -vvvv --log-time=1 > ~/pulse.log 2>&1

pulse_builtin_analog.log 409 KB View Download

pulse_headset_digital.log 415 KB View Download

pactl.log 29.9 KB View Download

Oh, your logs look like everything is working correctly.  Is your issue faster than normal playback or glitching with your WebAudio demo as you mention above? If you're only seeing this with your WebAudio demo (and not HTML5 or Flash) it's a different issue.  Please file a new bug with your report if this is the case.  I'll cc the right people there.

@dalecurtis: My issue is faster than normal playback. There is a steady crackle - it sounds like every second sound buffer is skipped and the crackle is the result of the change of amplitude over the skipped buffer.

The playback controls show time advancing at twice the normal rate - this is reflected by audioElem.currentTime.

I've seen the issue on a few occasions when watching video on various sites over the past few weeks (since I installed Ubuntu) though I havn't been able to reproduce the problem tonight. The WebAudio demo has identical symptoms (2x playback speed + steady crackle) except that I can reproduce the issue every time.

I had a go at compiling Chrome myself but I run out of memory when linking - heh. Is there a 32bit debug build (with symbols) somewhere? I'd like to have a look at what is going on.

Is what I've described consistent with your observations? If not I'll create a new ticket.

@steven: No, the WebAudio issue is something else related to how you have your nodes configured.  This bug is for faster-than-normal playback during HTML5 or Flash video playback or all WebAudio, not just the demo you have here.

I don't think you'll be able to build on 32bit Linux sadly. We use a special chroot which runs on a 64bit host for that build.

Once you file a new bug, I'll cc the right WebAudio folk.

Marking this as WontFix since tsched=yes fixes reported issues.  We've got a native Pulse Audio driver coming in M27 which should obviate the need for even needing to make that setting change.  If you're interested in that, please star  issue 32757 .

@dalecurtis: I've opened  issue 177912  for the WebAudio problems.

 Issue 175339  has been merged into this issue.

I am at google-chrome-27.0.1423.0_alpha184590 now, and still PulseAudio refers to Chrome as "ALSA plug-in". So apparently the information about "native Pulse Audio driver coming in M27" was wrong or means something other than version 27.

27 is still under active development :) I hope to get all the relevant patches landed this week.

I'll update once the next release rolls out, but my current version of the issue is as follows:

On Xubuntu 12.10 32-bit (Chromium Version 24.0.1312.56 Ubuntu 12.10), I can play all Flash videos with no issue.  I can play every HTML5 video I've encountered fine.  I've been able to play HTML5 MP3s with no issue EXCEPT for on google play.

On Google Play, the audio goes double-speed with significant distortion.  I do not experience the issue on other browsers.  Not sure if that helps narrow it down at all.

> 27 is still under active development :) I hope to get all the relevant patches
> landed this week.

Thanks for your reply!

 Issue 219244  has been merged into this issue.

The tsched workaround doesn't work. At first, it does fix the sound. It then results in completely dead sound after a day or so on the system - no YouTube video will play.

Please re-open this bug, and seek a proper fix.

Using the ALSA driver over Pulse is deprecated with M27.  If you're still seeing this issue even with tsched=1, please try the native Pulse audio driver on the Dev Channel:

http://www.chromium.org/getting-involved/dev-channel

If you still experience issues with M27, please take a look at the latest comments on  issue 32757  and file a new bug if nothing there helps you.  Please include the contents of /etc/pulse/daemon.conf and "pactl info" when reporting a bug related to Pulse Audio.

This still seems to be an issue with Version 28.0.1500.11 dev + Pulseaudio 1.3.0. HTML5 audio (YouTube, Google Music) speeds up  (increased pitch and speed) randomly, and requires a restart of pulseaudio to fix. 

Please see  issue 229918  and add your comments there. This bug tracks a different issue and is relatively old, so I'm going to close comments for it.

The workaround at present for  issue 229918  is to add a "default-sample-rate" value to your /etc/pulse/daemon.conf (or ~/.pulse/daemon.conf) and restart Pulse Audio.  We're discussing the best fix with a PulseAudio maintainer now. Thanks!

 Issue 128870  has been merged into this issue.