Browser freeze on Flash Streaming sites

[J-B]

Hi,

i am using Ubuntu 9.10 with the newest Pulseaudio.

ii pulseaudio 1:0.9.21-0ubuntu1~~karmic~ubuntuaudiodev2 PulseAudio sound server

If I open a site with a Flash stream (voice and video) the browser will freeze. If I kill Pulseaudio the Browser is accessible again.

I dont know how I can debug this.

In Ubuntu 8.10 it was fine.

I have try flash plugin 10.0.32.18 and 10.1(prerelease). I dont believe that it is a Flash Bug.

Here a Video to see the bug -> http://www.youtube.com/watch?v=cUAMmPosz2A

I hope you can fix this Bug ASAP.

[coling]

I'm not seeing those problems here, but someone did mention to me a probme with the firefox 3.6 beta + flash that sounded similar. What version of Firefox are you using?

It sounds like some kind of deadlock but we'd need gdb backtraces from this and preferably also the pulseaudio -vvvv log output (with a clear marker of where the freeze is ideally). With regards to the backtraces, please get a FF backtrace (as it will show the lock) as well as one form the PA server itself.

While it's in this state can you run other PA clients (e.g. mplayer -ao pulse someting.mp3) or does this lock up too?

[coling]

Oh forgot the link. See wiki:Community for info on generating backtraces etc.

[J-B]

Hi,

i am using

Firefox 3.5.6 Seamonkey 1.1.17 Chromium 4.0.258.0 (Ubuntu build 33210)

In all browsers the same.

: sink-input.c:     application.process.binary = "seamonkey-bin"
I: sink-input.c:     window.x11.display = ":0.0"
I: sink-input.c:     application.language = "de_DE.UTF-8"
I: sink-input.c:     application.process.machine_id = "c345c297a8b3122e6e87179c4ae99793"
I: sink-input.c:     application.process.session_id = "c345c297a8b3122e6e87179c4ae99793-1259263975.343060-368596815"
I: sink-input.c:     module-stream-restore.id = "sink-input-by-application-name:ALSA plug-in [seamonkey-bin]"
I: protocol-native.c: Requested tlength=500,05 ms, minreq=19,95 ms
D: protocol-native.c: Early requests mode enabled, configuring sink latency to minreq.
D: memblockq.c: memblockq requested: maxlength=4194304, tlength=11026, base=2, prebuf=8206, minreq=2822 maxrewind=0
D: memblockq.c: memblockq sanitized: maxlength=4194304, tlength=11026, base=2, prebuf=8206, minreq=2822 maxrewind=0
I: protocol-native.c: Final latency 628,04 ms = 244,08 ms + 2*127,98 ms + 128,00 ms
D: protocol-native.c: Requesting rewind due to end of underrun.
D: protocol-native.c: Underrun on 'ALSA Playback', 0 bytes in queue.

[J-B]

output pulseaudio -vvv

[coling]

Interesting.... the Requesting rewind on a queue with 0 bytes in the queue is odd.... I wonder if it is anyway related to ticket #725

Can you answer the other question asked? When this happens has PA locked up for all other clients or is it just locked for the FF process?

gdb backtraces would be nice if you can get them too.

[J-B]

When this happens has PA locked up for all other clients or is it just locked for the FF process?

Only the process. PA is working on other processes.

Here the Firefox debug log.

[J-B]

Firefox debug

[coling]

Actually, looking in more depth it seems that the alsa plugin simply doesn't supply any data. Quite why it reached the end of the under run, I don't know.

Certainly it seems there is a regression in the alsa plugin for some apps that I believe dtchen is looking at but I'm not sure this is related.

I can't reproduce here with the same versions of ff, flash and PA, so I'm leaning towards some kind of alsa problem but I'm far from certain (and I'm not sure where in ALSA this problem lies.

The fact that this is not being reported more widely tho' makes me think it could be hardware related in some capacity too. Not really sure here.

I'm not really super clued up on this stuff, but sadly the main guy who would know is off on holiday for a few weeks. One temporary work around is for you to compile up "libflashsupport" which you should find kicking around. This should let you use sound in flash + PA.

I'm going to take a stab at the right component here which is the alsa-pulse plugin (the libflashsupport compoennet is wrong as your flash is using the alsa plugin, not libflashsupport - as I mentioned above, libflashsupport may actually prove to be an OK workaround for now).

With regards your gdb logs, please ensure you give the juicy info: e.g. the "thread apply all bt full" before you exit :)

[J-B]

The fact that this is not being reported more widely tho' makes me think it could be hardware related in some capacity too. Not really sure here.

I have this problem in all other Hardware with Ubuntu 9.10. So, it cant be a Hardware problem.

My workaround is to kill PA. PA will restart automaticly. That is the easilier way :)

[J-B]

When do you mean can SP release a Patch for this Bug?

[lennart]

Most likely fixed with http://git.0pointer.de/?p=pulseaudio.git;a=patch;h=8d356659e69556fa25d0579a66084f820683e2b8

Please reopen if this does not in fact fix the problem. (it might be that pa's devcie access got suspended for some reason and cannot unsuspend it because some other app took the opportunity to block the audio device, which causes everything to stay stuck)