GNOME Bugzilla – Bug 343312
Assertion `file->wbuf_used_bytes < file->wbuf_size_bytes' failed.
Last modified: 2006-06-16 16:31:38 UTC
I have a .asounrdc setup to forward PCM data to a file, which has been created as a fifo (see below). When the fifo fills up, gstreamer hits the following assertion and causes the audio program to crash/end unexpectedly. pcm_file.c:112: snd_pcm_file_add_frames: Assertion `file->wbuf_used_bytes < file->wbuf_size_bytes' failed. I have reproduced this in banshee, rhythmbox and gst-launch with the following cmd line; gst-launch-0.10 filesrc location="/path/to/song.ogg" ! oggdemux ! vorbisdec ! audioconvert ! alsasink When running with gdb, it first hits a number of SIGPIPE's before hitting the assert. I am running Fedora Core 5 using gstreamer-0.10.4-1 rpm. My .asoundrc is setup as follows; pcm.!default { type plug slave.pcm "stdout" } pcm.stdout { type file file "/tmp/airportfifo" slave { pcm "hw:0,0" } } where /tmp/airportfifo has been created with "mknod /tmp/airportfifo p" Ideally I would expect gstreamer to "throw away" the unwritten data, or at least wait a short time before doing something more intelligent than asserting.
Created attachment 66420 [details] Backtrace obtained from banshee This is a backtrace obtained from running banshee and allowing the fifo to fill up.
a) I can't see any useful information in that back trace. Perhaps you could run with the GST_DEBUG=*sink:5 environment variable and redirect stderr to a file? (eg banshee 2> file.log) b) That assertion looks like it's inside the alsa libs to me - specifically inside ALSA's file output plugin. c) You might be able to avoid alsa altogether and just set banshee's output sink to something like 'identity ! audio/x-raw-int,rate=48000,width=16,depth=16 ! filesink sync=true location=/tmp/airportfifo'. Might need more parameters to the caps filter than that, but it's worth trying.
Created attachment 66421 [details] gst-launch with GST_DEBUG set The output of gst-launch with the GST_DEBUG variable set. Doesn't look to me like it contains any extra useful info, but you never know.
Created attachment 66422 [details] Banshee with GST_DEBUG var set
Regarding b), I guess this is something I need to carry on in ALSA then? Regarding c), I wasn't sure how I would go about altering the sink to banshee, so I altered my command line to gst-streamer and it seems unable to write to a fifo file. Normal files appeared to work fine. gst-launch-0.10 filesrc location="/path/to/music.ogg" ! oggdemux ! vorbisdec ! audioconvert ! filesink sync=true location=/tmp/airportfifo Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock ERROR: from element /pipeline0/filesink0: Error while writing to file "/tmp/airportfifo". Additional debug info: gstfilesink.c(426): gst_file_sink_render (): /pipeline0/filesink0: Illegal seek Execution ended after 1208000 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ... #>
*** Bug 343109 has been marked as a duplicate of this bug. ***
Following patch fixes the write to fifo. Writing to fifos, however, are quite different from normal files. They can signal SIGPIPE when the reader is shut down and block when opening the fifo if no reader is there. Not sure if we need to push all this logic in filesink. Reopen if not satisfactory, preferably a new bug that asks for better fifo handling. * plugins/elements/gstfilesink.c: (gst_file_sink_open_file), (gst_file_sink_close_file), (gst_file_sink_do_seek), (gst_file_sink_event), (gst_file_sink_render): * plugins/elements/gstfilesink.h: Check if we can seek in the file instead of assuming we always can. Post an error when we are asked to seek in a non-seekable file (like a fifo). Fixes #343312. Some cleanups.