long run gstreamer stops working without message
Krzysztof Konopko
krzysztof.konopko at youview.com
Wed Dec 5 03:15:50 PST 2012
Hi,
Just a guess... could it be something to do with clock/buffer timestamp
wrap-around or truncation?
The timestamps are 64 bit integers which gives roughly 10^18. The base
time unit is ns (10^-9) so if we talking about hours we reach values at
most ~10^13. Feels like there's still enough capacity in the timestamp
type. But maybe specifically alsasink or the the hardware itself
truncates timestamps and doesn't handle wrap-arounds?
Just a hitch. Might be completely irrelevant...
Cheers,
Kris
On 05/12/12 10:53, Thomas DEBESSE wrote:
> Hello, I always encounters strange behavior when I use gstreamer for
> long durations.
> For example, if I use this pipeline :
> gst-launch-0.10 jackaudiosrc ! "audio/x-raw-float" ! audioconvert !
> audioresample ! "audio/x-raw-int, rate=44100, width=16" ! alsasink
> device="hw:1" sync=0
>
> On this example, the alsasink module uses the soundcard directly,
> without alsa any module (no plug, no dmix).
>
> After about 14 hours, the pipeline stop to play sound. And logs say nothing !
> I have no other solutions : I must restart the pipeline regularly (set
> gst.STATE_NULL then set gst.STATE_PLAYING).
>
> I encounter similar problems with various pipelines, as I wrote a few
> months ago. The common point is that it breaks after several hours of
> usage, and I use the modules audioresample, audioconvert, and
> alsasink.
> I use audioresample and audioconvert in other pipelines without
> alsasink, and I have no problem when I use some others modules that
> are not alsasink (I don't have problems with jackaudiosink and
> udpsink).
>
> Does someone have an idea ?
>
>
> 2012/7/6 Thomas DEBESSE <thomas.debesse at rcf.fr>:
>> Hello, I have a strange problem : I use gstreamer to stream sound
>> between two computer, it's work nicely but after a few hours, I get
>> silence without information in the logs. I use also gstreamer to
>> connect two audio interfaces (one play the sound recorded by the
>> other). It's work nicely but after a few hours, I get noise (the sound
>> is completely distorted).
>>
>> ## First case
>>
>> On a computer (sender)
>>
>> export GST_DEBUG="3"
>>
>> gst-launch-0.10 -v alsasrc device=intel_in \
>> ! audioconvert \
>> ! audioresample \
>> ! queue max-size-buffers=100 leaky=downstream \
>> ! "audio/x-raw-int,rate=44100,width=16,channels=2" \
>> ! celtenc cbr=true bitrate=64 framesize=128 \
>> ! rtpceltpay \
>> ! udpsink host=prjevalski port=4951
>>
>> I have also tested with "queue max-size-buffers=100 leaky=downstream"
>> after "audioresample" element.
>>
>> on another computer (receiver)
>>
>> export GST_DEBUG="3"
>>
>> caps="application/x-rtp, media=(string)audio, clock-rate=(int)44100,
>> encoding-name=(string)CELT, encoding-params=(string)2,
>> frame-size=(string)480, payload=(int)96"
>>
>> gst-launch-0.10 -v udpsrc uri="udp://prjevalski:4951" caps="$caps" \
>> ! gstrtpjitterbuffer latency=60 drop-on-latency=true \
>> ! rtpceltdepay \
>> ! celtdec \
>> ! audioconvert \
>> ! audioresample \
>> ! "audio/x-raw-int,rate=44100,width=16,channels=2" \
>> ! alsasink device=nvidia_front sync=false
>>
>> I've also tested with "queue max-size-buffers=100 leaky=downstream"
>> before "audioconvert" element.
>>
>> The sound is transmitted for several hours before I get silence.
>>
>> For example, at 5 PM yesterday I launched these commands, the last
>> gstreamer's output on sender and receiver are form 5 am, but this
>> morning but no sound came out.
>> In tcpdump, I still see a rtp stream
>>
>> I built the same pipeline using python.
>> When silence occur, a simple (stopping and replaying the receiver
>> gstreamer pipeline)
>>
>> receiver.set_state(gst.STATE_NULL)
>> receiver.set_state(gst.STATE_PLAYING)
>>
>> gives me the sound.
>>
>> Both computers are on a local network, (I first had this problem using
>> internet but using a local network the bug also occurs)
>> I configure my alsa interface in this way (using both plug and
>> dmix/dsnoop module) :
>>
>> pcm.intel_front {
>> type plug
>> slave.pcm {
>> type dmix
>> ipc_key 1024
>> slave {
>> pcm "front:0,0"
>> }
>> }
>> }
>>
>> pcm.intel_in {
>> type plug
>> slave.pcm {
>> type dsnoop
>> ipc_key 1024
>> slave {
>> pcm "hw:0,0"
>> }
>> }
>> }
>>
>> I tested these alsa interfaces :
>>
>> lspci :
>> 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM
>> (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
>> 05:04.0 Multimedia audio controller: Creative Labs CA0106 Soundblaster
>> # Audigy SE
>> 00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2)
>> lsusb :
>> Bus 003 Device 003: ID 06f8:c001 Guillemot Corp. # Muse Pocket LT3
>>
>> I get the bug with all of them.
>>
>> ## Second case
>>
>> Also, I use another pipeline :
>> export GST_DEBUG="3"
>>
>> gst-launch-0.10 -v alsasrc device=intel_in \
>> ! audioconvert \
>> ! audioresample \
>> ! "audio/x-raw-int,rate=44100,width=16,channels=2" \
>> ! alsasink device=audigy_front sync=false \
>>
>> I have also tested with a "queue" after "audioresample" element.
>>
>> The purpose of this pipeline is simply to play on a alsa interface
>> which is recorded from another alsa interface.
>> The sound is okay for several hours until it becomes suddenly a very
>> ugly mixture.
>> I've launched this pipeline yesterday at about 5 PM, the sound was
>> ugly this morning, and in a recording the sound is good and then the
>> sound deteriorates suddenly.
>>
>> The logs report nothing since 5 PM :
>>
>> 0:00:00.446042222 27052 0x98e6640 INFO GST_STATES
>> gstbin.c:2443:gst_bin_change_state_func:<pipeline0> child 'alsasink0'
>> changed state to 4(PLAYING) successfully
>> 0:00:00.446067645 27052 0x98e6640 INFO GST_STATES
>> gstelement.c:2236:gst_element_continue_state:<capsfilter0> completed
>> state change to PLAYING
>> 0:00:00.446083010 27052 0x98e6640 INFO GST_STATES
>> gstbin.c:2443:gst_bin_change_state_func:<pipeline0> child
>> 'capsfilter0' changed state to 4(PLAYING) successfully
>> 0:00:00.446100890 27052 0x98e6640 INFO GST_STATES
>> gstelement.c:2236:gst_element_continue_state:<queue0> completed state
>> change to PLAYING
>> 0:00:00.446114859 27052 0x98e6640 INFO GST_STATES
>> gstbin.c:2443:gst_bin_change_state_func:<pipeline0> child 'queue0'
>> changed state to 4(PLAYING) successfully
>> 0:00:00.446132459 27052 0x98e6640 INFO GST_STATES
>> gstelement.c:2236:gst_element_continue_state:<audioresample0>
>> completed state change to PLAYING
>> 0:00:00.446146428 27052 0x98e6640 INFO GST_STATES
>> gstbin.c:2443:gst_bin_change_state_func:<pipeline0> child
>> 'audioresample0' changed state to 4(PLAYING) successfully
>> 0:00:00.446163749 27052 0x98e6640 INFO GST_STATES
>> gstelement.c:2236:gst_element_continue_state:<audioconvert0> completed
>> state change to PLAYING
>> 0:00:00.446177159 27052 0x98e6640 INFO GST_STATES
>> gstbin.c:2443:gst_bin_change_state_func:<pipeline0> child
>> 'audioconvert0' changed state to 4(PLAYING) successfully
>> 0:00:00.446193642 27052 0x98e6640 INFO GST_STATES
>> gstelement.c:2236:gst_element_continue_state:<alsasrc0> completed
>> state change to PLAYING
>> 0:00:00.446207331 27052 0x98e6640 INFO GST_STATES
>> gstbin.c:2443:gst_bin_change_state_func:<pipeline0> child 'alsasrc0'
>> changed state to 4(PLAYING) successfully
>> 0:00:00.446226608 27052 0x98e6640 INFO GST_STATES
>> gstelement.c:2236:gst_element_continue_state:<pipeline0> completed
>> state change to PLAYING
>> 0:00:00.446240297 27052 0x98e6640 INFO GST_STATES
>> gstelement.c:2249:gst_element_continue_state:<pipeline0> posting
>> state-changed PAUSED to PLAYING
>> [then nothing]
>>
>> ## Some system information
>>
>> I'm using Debian Squeeze with Gstreamer 0.10
>>
>> some "apt-cache show" output :
>>
>> libgstreamer0.10-0
>> Version: 0.10.30-1
>> libcelt0-0
>> Version: 0.7.1-1
>> libasound2
>> Version: 1.0.23-2.1
>>
>> some "gst-inspect-0.10" output :
>>
>> alsasrc
>> Long name: Audio source (ALSA)
>> Filename: /usr/lib/gstreamer-0.10/libgstalsa.so
>> Version: 0.10.30
>> Source module: gst-plugins-base
>> alsasink
>> Long name: Audio sink (ALSA)
>> Filename: /usr/lib/gstreamer-0.10/libgstalsa.so
>> Version: 0.10.30
>> Source module: gst-plugins-base
>> audioconvert
>> Long name: Audio converter
>> Filename: /usr/lib/gstreamer-0.10/libgstaudioconvert.so
>> Version: 0.10.30
>> Source module: gst-plugins-base
>> audioresample
>> Long name: Audio resampler
>> Filename: /usr/lib/gstreamer-0.10/libgstaudioresample.so
>> Version: 0.10.30
>> Source module: gst-plugins-base
>> queue
>> Long name: Queue
>> Filename: /usr/lib/gstreamer-0.10/libgstcoreelements.so
>> Version: 0.10.30
>> Source module: gstreamer
>> celtenc
>> Long name: Celt audio encoder
>> Filename: /usr/lib/gstreamer-0.10/libgstcelt.so
>> Version: 0.10.19
>> Source module: gst-plugins-bad
>> celtdec
>> Long name: Celt audio decoder
>> Filename: /usr/lib/gstreamer-0.10/libgstcelt.so
>> Version: 0.10.19
>> Source module: gst-plugins-bad
>> rtpceltpay
>> Long name: RTP CELT payloader
>> Filename: /usr/lib/gstreamer-0.10/libgstrtp.so
>> Version: 0.10.24
>> Source module: gst-plugins-good
>> rtpceltdepay
>> Long name: RTP CELT depayloader
>> Filename: /usr/lib/gstreamer-0.10/libgstrtp.so
>> Version: 0.10.24
>> Source module: gst-plugins-good
>> gstrtpjitterbuffer
>> Long name: RTP packet jitter-buffer
>> Filename: /usr/lib/gstreamer-0.10/libgstrtpmanager.so
>> Version: 0.10.24
>> Source module: gst-plugins-good
>> udpsrc
>> Long name: UDP packet receiver
>> Filename: /usr/lib/gstreamer-0.10/libgstudp.so
>> Version: 0.10.24
>> Source module: gst-plugins-good
>> udpsink
>> Long name: UDP packet sender
>> Filename: /usr/lib/gstreamer-0.10/libgstudp.so
>> Version: 0.10.24
>> Source module: gst-plugins-good
>>
>> Do you think I forgot a few items or settings, or have I found a bug?
>>
>> Thanks!
>>
>> --
>> Thomas DEBESSE
>> RCF Méditerrannée
>
>
>
More information about the gstreamer-devel
mailing list