GNOME Bugzilla – Bug 620540
[pulsesink] pa_stream_write() failed: Invalid argument
Last modified: 2010-06-09 16:02:40 UTC
Created attachment 162723 [details] bzip2 log file git version : d72a2fb6da94989122d8005d8c674bef6371ad04 When playing some files I get this error from pulsesink : error: pa_stream_write() failed: Invalid argument The file is a asf/wmv/wma with stereo 44.1kHz stream. attached is a GST_DEBUG=2,pulse*:5,*sink:5,*ERR*:5 totem /data/truc/20100201_008_enhanced.wmv > log 2>&1
Introduced by this commit: commit 66a76d1f65141ec1180809d2fc258b1e4ecb9768 Author: Pierre-Louis Bossart <pierre-louis.bossart@intel.com> Date: Tue Jun 1 18:54:41 2010 -0500 pulsesink: optimize communication with PulseAudio using pa_stream_begin_write Reverting to the commit before fixes the problems.
works for me with wma files (using fluwmadec). Can you please provide your bitstream? $ gst-launch filesrc location=//home/ume/AURAL/Audio/theTest-3mn-320.wma ! decodebin ! pulsesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... (gst-launch-0.10:8160): GStreamer-WARNING **: Trying to set empty string on taglist field 'title'. Please file a bug. (gst-launch-0.10:8160): GStreamer-WARNING **: Trying to set empty string on taglist field 'artist'. Please file a bug. (gst-launch-0.10:8160): GStreamer-WARNING **: Trying to set empty string on taglist field 'copyright'. Please file a bug. (gst-launch-0.10:8160): GStreamer-WARNING **: Trying to set empty string on taglist field 'description'. Please file a bug. (gst-launch-0.10:8160): GStreamer-WARNING **: Trying to set empty string on taglist field 'rating'. Please file a bug. Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstPulseSinkClock Got EOS from element "pipeline0". Execution ended after 17918584828 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ...
Files that error out : http://people.collabora.co.uk/~edward/medias/enoughrope_seinfeld1.wmv http://samples.mplayerhq.hu/A-codecs/WMA/Bangles%2001%20-%20Walk%20Like%20An%20Egyptian.wma Some other files don't error out, but since that commit they result in choppy playback and the following output: pulsesink.c:558:gst_pulsering_stream_underflow_cb:<autoaudiosink1-actual-sink-pulse> Got underflow http://samples.mplayerhq.hu/A-codecs/WMA2/nintendothemesacappellax.wmv http://samples.mplayerhq.hu/A-codecs/WMA2/polski-rajd.wmv http://samples.mplayerhq.hu/A-codecs/WMA2/raam28mb.wmv Finally some NON-WMA files result in that 'underflow' warning but without any noticeable audio disturbance: http://samples.mplayerhq.hu/A-codecs/AAC/zx.eva.renewal.01.divx511.mkv All files play flawlessly when that commit is reverted. Tested with all gstreamer modules from git head as of today (no proprietary plugins due to impossibility to debug them).
Both files which 'error out' play flawlessly on my Fedora13 latop with pulseaudio stable-queue and latest gstreamer git + Fluwmadec. Same for all the others tracks. which plugin are you using for wma? and which version of PA are you using? Thanks for your feedback.
gst-ffmpeg is used for decoding pulseaudio-0.9.21.2
I can reproduce this problem with Edward's test files - seems to be a problem that's only triggered with the plugins that are widely used (though not with the proprietary fluendo ones). Testing with third-party proprietary plugins is fine, but it's important to also test with the free plugins.
Oh, and this was with: - Current git of all gstreamer modules - Ubuntu 9.10 - Pulseaudio package version: 1:0.9.19-0ubuntu4
Reproduced with ffmpeg and the Bangles clip. There's a difference between the behavior of the ffmpeg and fluendo wma decoders. the former will provide 65536 bytes at once, while the latter provides 8192 bytes (which is consistent with the WMA frame size). This is really odd because in the mp3 case both decoders provide one frame at a time. Providing 64k at once isn't quite compatible with the patch I provided, with was meant to adjust the granularity of pulsesink-pulseaudio transfers to the latency-time argument. Anyone knows why ffmpeg would do such a large buffering?
This would cause problems with wavpack too then. wavpack uses frames of 0.5-1 seconds with 32 bit samples, i.e. usually above 300kbytes per frame.
The problem isn't the decoders, audiosinks should work with any incoming buffer sizes.
Yes of course, but at least we know now what causes the problem :)
Probably found the problem... if more than buf->spec.segsize should be written pbuf->m_writable is clamped but all samples are written nonetheless. Also if the buffer is full it should be passed to PA after writing to it instead of waiting for the next round.
Should be fixed now by these commits commit bd5987a3d23fe17d4253854149c0c53d6bbc5122 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Wed Jun 9 16:22:27 2010 +0200 pulsesink: Flush shm buffer immediately if it's full commit 57813d469fcdfc09ac57951979397e36555b2362 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Wed Jun 9 16:21:55 2010 +0200 pulsesink: Fix writing of buffers larger than segsize Fixes bug #620540. commit b78a27beb22a535c60daf6a5da06673b2b554bd5 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Wed Jun 9 15:42:37 2010 +0200 pulsesink: Fix playback if PA doesn't give us a large enough shared memory b
Flawless :) Thanks a lot
Good job Sebastian, you beat me to it. I had more or less the same fixes but your code is much nicer. Thanks!