Description of problem: When playing a DVD totem displays a message: "An error occured" "pa_stream_writable_size() failed: Connection terminated" And the DVD refuses to play. Version-Release number of selected component (if applicable): totem-nautilus-2.28.5-3.fc12.i686 totem-youtube-2.28.5-3.fc12.i686 totem-2.28.5-3.fc12.i686 totem-pl-parser-2.28.2-1.fc12.i686 How reproducible: Always Steps to Reproduce: 1. Insert a DVD video in the pc's dvd player. 2. Use totem (movieplayer) to play the DVD 3. Actual results: Totem stops playing with a message "An error occured" Expected results: Totem playing the DVD without further issues. Additional info: see attachment.
Created attachment 395248 [details] Totem crash output from terminal
I know there is a ticket for this at pulseaudio-tickets. It seems I am not the only one having this problem. Strange thing however is that this error does not occur using vlc or xine, only totem as far as i can see.
I get the same error in playing some avi and mkv files (not all) on up to date Fedora 13 prerelease. $ totem file.mkv ** Message: Error: pa_stream_writable_size() failed: Connection terminated pulsesink.c(1388): gst_pulseringbuffer_commit (): /GstPlayBin2:play/GstPlaySink:playsink0/GstBin:abin/GstBin:audiosinkbin/GstGConfAudioSink:audio-sink/GstBin:bin2/GstAutoAudioSink:autoaudiosink1/GstPulseSink:autoaudiosink1-actual-sink-pulse Version: totem.i686 2.30.0-2.fc13 No problems with vlc-player.
Just switched from Fedora 12 to Fedora 13. The same error pops up again. It appears only when playing dvd's or other media files that contain more then 2 (stereo) sound channels.
I also got this behaviour from totem. The same files could be played by mplayer with absolutely no problem.
Seeing this in F-13 trying to play DVDs and watch TV using gnome-dvb-daemon
As far as I can tell this happens with AC3 streams regardless of being stereo (2-ch) or sourround (3.1/5.1) sound. In my triage tests, the problem seems to be in the a52dec driver, part of gstreamer-plugins-ugly. I wonder if this is something that should be reported to the rpmfusion guys.
I'd like to report this to the rpmfusion guys but I don't know how to do that. Can somebody tell me where and how bugs can be reported for the gstreamer-plugins-ugly at rpmfusion?
(In reply to comment #8) > I'd like to report this to the rpmfusion guys but I don't know how to do that. > > Can somebody tell me where and how bugs can be reported for the > gstreamer-plugins-ugly at rpmfusion? You need to open a bugzilla account at their site. (if you do, please post the bug number here so we can help push that shovel :-) BTW, doin more prodding, I think there is a conflict with gstreamer-ffmpeg (another rpmfusion package) but I can't pinpoint the problem there.
Done, thank you.
Eddie's bug #1258 is viewable at http://bugzilla.rpmfusion.org/show_bug.cgi?id=1258 (Thanks for taking the time to follow up over there!) As a "metoo", I'm seeing this issue playing .mkv files in totem, all of which play fine in vlc-1.0.6-1.fc13.x86_64. The totem error message coincides with the pulseaudio daemon crashing and being restarted, which may indicate an issue on the pulse side as well -- no matter what rpmfusion's gstreamer plugins are doing wrong to trigger this, they shouldn't be able to take out pulseaudio.
As Markku Korkeala in comment #3 shows, there is an error in the gstreamer pulse audio output (sink) plugin which is part of gstreamer-plugins-good, changing the component of bug 566915 to gstreamer-plugins-good.
Created a bug for gstreamer-plugings-good at freedesktop.org https://bugs.freedesktop.org/show_bug.cgi?id=29366 Hopefully this will speed-up things a little.
Created a bug for gstreamer-plugings-good at bugzilla.gnome.org: https://bugzilla.gnome.org/show_bug.cgi?id=625948
Is it just me, or has this problem dissipated somewhere in the intervening months since our inital reports? I can't put my finger on exactly when it happened, or what update made the difference, but it's been some time (weeks) since I last recall encountering this bug. My quickie attempts to trigger it just now have met with complete "failure". (Meaning, I've successfully played various media files containing AC3 audio streams in totem, and had nary a hiccup from pulseaudio. Back when there was a problem with AC3 streams, it was always quite easy to trigger a pulseaudio crash.) Are people still seeing these errors, with the latest gstreamer/totem/pulseaudio packages from updates?
The bug is still here. No change.
I have a fully updated F13 system (which I just installed a couple of days ago) which is still running into this bug.
I think my bug 622330 may be the same as yours. (Why is it you always find the duplicate after reporting a new bug?) I think it may be a sample rate problem. Can you try this command `gst-launch audiotestsrc ! audioresample ! audio/x-raw-int,rate=48000 ! pulsesink` and then this one: `gst-launch audiotestsrc ! audioresample ! audio/x-raw-int,rate=44100 ! pulsesink` You should hear an annoying tone if it's working. For me, 48000 is the native sound card rate, and plays correctly. But 44100 is not, and it fails to play.
It looks like I'm experiencing the same bug - my sound card has a native sample rate of 44.1 kHz, so $ gst-launch audiotestsrc ! audioresample ! audio/x-raw-int,rate=44100 ! pulsesink works fine for me, but trying the command with a sample rate of 48 kHz seems to crash pulseaudio. $ gst-launch audiotestsrc ! audioresample ! audio/x-raw-int,rate=48000 ! pulsesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstPulseSinkClock ERROR: from element /GstPipeline:pipeline0/GstPulseSink:pulsesink0: pa_stream_writable_size() failed: Connection terminated Additional debug info: pulsesink.c(1571): gst_pulseringbuffer_commit (): /GstPipeline:pipeline0/GstPulseSink:pulsesink0 Execution ended after 37268425241 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... Also, the files which are triggering this bug for me all have a sample rate of 48 kHz.
(In reply to comment #19) > It looks like I'm experiencing the same bug - my sound card has a native sample > rate of 44.1 kHz, so Its the same with me. mp3 audio at 44.1 is fine. Looking at the output of alsa-info my sound card support 44100, 48000 and 96000 and with various tests it seems it works fine with 41.1 kHz and 48K native but not at non native rates like 32k.
How can you test if the problem is in pulseaudio or alsa? Is there a way of sending the stream directly to the alsa? Can you bypass pulseaudio?
You can send to ALSA using this line: gst-launch audiotestsrc ! audio/x-raw-int,rate=44100 ! alsasink Note, I removed the audioresample because specifying a format there will automatically set audiotestsrc's format and that reduces the amount of work to be done. Also, a very important point is that the default ALSA device outputs back to pulseaudio. This is so that older applications will still be routed through pulseaudio. To bypass pulseaudio entirely, first use `aplay -L` to list out the name of your sound card as seen by ALSA. Then you can use this line: gst-launch audiotestsrc ! audio/x-raw-int,rate=44100 ! alsasink device=<name of device> However, it is quite probable that your sound card only supports one sample rate. Pulseaudio is supposed to open the device at that rate and resample any other input during mixing. On my card, I cannot use any rate I want, only the native rate of 48kHz (HW limitation). I can send any rate through GST->ALSA->ALSA/PA bridge->PA->ALSA (working correctly). However, I can send only the device rate through GST->PA->ALSA. This last one is the one that is broken, since newer applications will send to PA and expect it to resample during mixing.
just have tried your command with sample rate 44100 en 4800 to devices front,rear and surround41 and all went well. I heard the test sound. Does this mean that alsa is ok and the failure should be in pa?
gst-launch audiotestsrc ! audio/x-raw-int,rate=48000 ! pulsesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstPulseSinkClock ERROR: from element /GstPipeline:pipeline0/GstPulseSink:pulsesink0: pa_stream_writable_size() failed: Connection terminated Additional debug info: pulsesink.c(1571): gst_pulseringbuffer_commit (): /GstPipeline:pipeline0/GstPulseSink:pulsesink0 Execution ended after 13612581784 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ...
this is still an issue on Fedora 14
So does anyone have any idea here? I've been forced to workaround by removing pulsesink so that auto will go through alsasink, but it uses up a ton of CPU, and sometimes freezes totem when seeking.
Created attachment 457252 [details] Some problem with nondvd video file Same problem with a XVID MPEG-4 (Dolby Digital (AC-3) Surround 5.1 48000 Hz 448 kbps) video file. Isnt a dvd file. This wasnt happening until I try to install devede and dvd movie support for brasero. Maybe is connect with some dependency of them, like ffmpeg.
Elliot: The problem is that there resampling is taking a long time which is leading to pulseaudio falling behind or using so much CPU that it is being killed off. A "workaround" is to set a cheaper --resample-method (e.g. speex-float-2 or ffmpeg) for pulseaudio. This will cost you sound quality but should make this issue harder to trigger.
In that case, I tried out the other resampling methods. I get no sound and it eventually dies with the following methods: src-sinc-best-quality, src-sinc-medium-quality, src-sinc-fastest, speex-float/fixed-0 to 10, and copy. The two, src-linear and peaks, make a few sputters, but then crash, bug 651676. These two work, with terrible quality: src-zero-order-hold, and trivial. And ffmpeg seems to be OK, but causes a bit of stuttering at the start. I find it hard to believe that ALL of those methods require so much CPU. It works just fine on my laptop, but that's a different card (but it still has a limited sample rate), so not really a great comparison. It's also 32-bit instead of 64-bit, if that makes any difference.
I've reproduced this issue on both 32-bit and 64-bit versions of Fedora (on the same computer) - as far as I can see there's no difference, but then I'm not much use when it comes to gauging audio quality. Oddly enough, this issue doesn't seem to occur for me when playing FLAC files with a non-native sample rate. CPU usage is still rather high, but playback goes just fine.
when I use in daemon.conf: resample-method = trivial the problem is gone. regards, Eddie.
(In reply to comment #31) > when I use in daemon.conf: > > resample-method = trivial > > the problem is gone. > > regards, Eddie. I can confirm that this works. I was hitting this problem by playing back a DVD as part of working on phonon-gstreamer. Using gst-launch, I was able to reproduce the phonon-gstreamer pipeline: gst-launch rsndvdbin ! ffmpegcolorspace ! queue ! dvdspu ! xvimagesink rsndvdbin0. ! queue max-size-buffers=1 ! dvdspu0.subpicture rsndvdbin0. ! queue ! pulsesink When I swap out pulsesink for alsasink, the problem vanishes. When I put pulsesink back in with resample-method=trivial in the configuration, the problem also vanishes.
The Ubuntu folks have a bandaid in gstreamer for what looks like this problem, which involves sending pulseaudio larger packets - https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/644644/comments/101 .
echo "resample-method = trivial" >> /etc/pulse/daemon.conf Works for Scientific Linux 6 beta 3, so I presume it will work for RHEL6 and CenOS 6 as well. Perhaps the Ubuntu band-aid in comment 33 will be pushed out to the rest of us. Thanks, Dave
Good news - the bandaid has gone into upstream gstreamer (http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=1e2c1467ae042a3c6bb1a6bc0c07aeff13ec5edb ) so part of the fix is already in F15 and it looks like further fixes will be rolled into the next pulseaudio upstream release ( http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=fe7b972487bfc85940d2d427096fd9189af3bd7a and http://git.0pointer.de/?p=pulseaudio.git;a=commit;h=74eb4d892137f6ba4d87b011e46118668187307b ).
I gave up the emu10k1 and bought a new system with intel hd audio onboard. In windows this card does perfectly multichannel audio. So i thought this would finally solve my multichannel audio problem in linux. but what do you think? IT DOESN'T WORK EITHER!!!!!!!!!!! It doesn't even provide me with an option to enable surround So, now I also can forget about 4.1 surround audio and throw away my surround speakers as well! I feel pretty much screwed!
I've got the same problem on totem while playing mpg movies. An error occurred pa_stream_writable_size() failed: Connection terminated An error occurred Disconnected: Connection terminated An error occurred pa_stream_cork() failed: Connection terminated An error occurred Disconnected: Connection terminated
Does pulseaudio realy needs to resample? If my sound card can do 44100 and 48000 Hz, why even bother?