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

Issue 116435 link

Starred by 142 users

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

Issue metadata

Status: WontFix
Owner:
Closed: Feb 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

PulseAudio sometimes issues audio callbacks too quickly, leading to sped up audio in flash and html5.

Reported by beze...@gmail.com, Mar 1 2012

Issue description

After updating to version 19.0.1055.1 flash had stopped working. That issue was described at http://code.google.com/p/chromium/issues/detail?id=116238.
After performing "sudo apt-get install libssl0.9.8", like were suggested in comments, flash had been restored, however it started working improperly.


Chrome Version       : 19.0.1055.1
OS Version: (X)Ubuntu GNU/Linux 11.10 (x64)
URLs (if applicable) : any website with flash content
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5:
  Firefox 10.0.2: OK
     IE 7/8/9:

What steps will reproduce the problem?
1. Open some youtube video
2. Open some online radio site, e.g. http://myradio.ua/flashplayer/2
3. Open some website containing flash ads.

What is the expected result?
Flash content should play properly, like in other browsers.

What happens instead?
All flash content (audio, video, ads) plays in 2 times faster than usually.

More information:
Any other dynamic content (like html5 video or gif images) works well. Moreover, if I disable chrome flash (first one) on chrome://plugins page, flash also starts working well.

Description from chrome://plugins page:
1) Name:	Shockwave Flash
Description:	Shockwave Flash 11.2 r31
Version:	11.2.31.109
Location:	/opt/google/chrome/PepperFlash/libpepflashplayer.so
Type:	PPAPI (out-of-process)
2) Name:	Shockwave Flash
Version:	11.1 r102
Location:	/usr/lib/adobe-flashplugin/libflashplayer.so
Type:	NPAPI


UserAgentString: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.24 (KHTML, like Gecko) Chrome/19.0.1055.1 Safari/535.24

Thanks
 
Showing comments 46 - 145 of 145 Older
 Issue 120801  has been merged into this issue.
Cc: imasaki@chromium.org tweisberg@chromium.org alek...@chromium.org
 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

Comment 49 by d...@djm.net.au, Aug 23 2012

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

Comment 50 Deleted

Comment 51 Deleted

Comment 52 by Deleted ...@, Sep 25 2012

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.

Comment 54 by hpw@google.com, Oct 4 2012

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?
Labels: Action-FeedbackNeeded
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.

Comment 56 by beze...@gmail.com, Oct 8 2012

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.

Comment 58 by garf@google.com, Oct 11 2012

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.

Comment 60 by pdk...@gmail.com, Nov 1 2012

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.
Labels: Feature-Media-Audio
Status: Untriaged

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

Same problem here.

OS: Ubuntu 12.04 64bit
Chrome: 21.0.1180.79
PepperFlash: 11.3.31.227
Labels: -Action-FeedbackNeeded
Cc: -alek...@chromium.org
Cc: -tweisberg@chromium.org
Cc: -imasaki@chromium.org

Comment 67 by relga...@gmail.com, Dec 15 2012

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.
Summary: PulseAudio sometimes issues audio callbacks too quickly, leading to sped up audio in flash and html5. (was: Flash works improperly: flash content plays in two times faster than usually)
Cc: dalecur...@chromium.org scherkus@chromium.org
 Issue 128870  has been merged into this issue.

Comment 71 by mbl...@mbligh.org, Jan 18 2013

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.

Comment 73 by jjh...@bueller.us, Jan 18 2013

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        

Comment 74 by jchar...@gmail.com, Jan 18 2013

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.
Cc: -dalecur...@chromium.org -scherkus@chromium.org xians@chromium.org
Owner: dalecur...@chromium.org
Status: Started
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.

Comment 79 by mlo...@gmail.com, Jan 19 2013

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.

Comment 81 by jchar...@gmail.com, Jan 20 2013

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

Comment 82 by asloane@google.com, Jan 22 2013

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.

Comment 84 by asloane@google.com, Jan 23 2013

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

Cc: -viettrungluu@chromium.org
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!

Comment 87 by jchar...@gmail.com, Jan 27 2013

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.

Comment 90 by jchar...@gmail.com, Jan 28 2013

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!

Comment 92 by Deleted ...@, Jan 29 2013

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.

Comment 93 by jchar...@gmail.com, Jan 29 2013

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!

Comment 95 by jchar...@gmail.com, Jan 30 2013

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.

Comment 97 by jchar...@gmail.com, Jan 31 2013

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.
Status: WontFix
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!
Project Member

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

Labels: -Area-Internals -Feature-Flash -Feature-Media-Audio Cr-Internals-Media-Audio Cr-Content-Plugins-Flash Cr-Internals
 Issue 219244  has been merged into this issue.

Comment 138 by mbl...@mbligh.org, Mar 25 2013

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

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

Labels: Cr-Blink
Project Member

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

Labels: -Cr-Content-Plugins-Flash Cr-Internals-Plugins-Flash
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. 
Labels: Restrict-AddIssueComment-EditIssue
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!
Cc: -jeffreyc@chromium.org
Cc: viettrungluu@chromium.org scherkus@chromium.org dalecur...@chromium.org
 Issue 128870  has been merged into this issue.
Showing comments 46 - 145 of 145 Older

Sign in to add a comment