GNOME Bugzilla – Bug 561891
Some output audio sink are not playing
Last modified: 2010-03-25 15:00:27 UTC
Hi, I am trying to output some audio to pulseaudio, and there are some outputs that just don't work. I hear sound for 1 sec, and that's it! (under Ubuntu 8.04 and 8.10, amd64 both) Here is an example: gst-launch pulsesrc ! audioconvert ! pulsesink gst-launch dv1394src skip=3 ! dvdemux name=d ! dvdec quality=1 ! xvimagesink d. ! queue ! audioconvert ! autoaudiosink Tried alsasink, pulsesink, autoaudiosink and gconfaudiosink. All the same thing. But if I output to ossink: gst-launch pulsesrc ! audioconvert ! osssink it works... So, I don't know if it pulseaudio of gstreamer, but it looks as it could be gstreamer... Ah, yeah, playing a video using decodebin will work. gst-launch filesrc location=somefile.mp3 ! decodebin ! audioconvert ! pulsesink I tried playing will audio format, different output (Alsa, pulse directly).. nothing seems to work. Alway 1 sec audio and then nothing... The streams seems to lock as I can see the stream in the Pulseaudio server (using pavucontrol). No error, no warnings... I am using gstreamer-java and I found that out by testing... Also, in Ubuntu, in gstreamer-properties, the "Test" button does the same behaviour for the microphone...
pulsesrc and pulsesink don't work well together because of the bursty nature in which they work. For the DV case, you'll need a queue in front of dvdec so that audio is not blocked by the videosink.
Hi, Just retested this adding queue in front of dvdec and it still does not work gst-launch dv1394src ! dvdemux name=d ! queue ! dvdec quality=1 ! xvimagesink d. ! queue ! audioconvert ! pulsesink But if I output to osssink, it works gst-launch dv1394src ! dvdemux name=d ! queue ! dvdec quality=1 ! xvimagesink d. ! queue ! audioconvert ! osssink To to make sure, I tried this also: padsp gst-launch dv1394src ! dvdemux name=d ! queue ! dvdec quality=1 ! xvimagesink d. ! queue ! audioconvert ! osssink And it does not work either... It is pulseaudio or gstreamer that is giving a problem?
Hi again, Just made interesting discovery: If you do this: gst-launch -v pulsesrc slave-method=2 ! pulsesink slave-method=2 It will work. I had also some results playing with the latency value, but this last one with the slave-method=2 gives exactly what I was trying to achieve. I'm gonna test with the DV1394 to see if I can make it work the same way.
Hi, I made some more tests with dv1394 and adding slave-method=2 to pulsesink does not solve completely the problem. Sometime I have 1 sec of audio, and other time I have more. And sometimes, I can have audio for longer period (5 mins), but eventually, it drops. Video still is playing during this time. It's really strange, it looks like a buffer problem or a clock sync problem. I am mostly using gstreamer-java, but do all my testing using gst-launch and in both implementations, I have similar behaviour. Using gstreamer-java, I found out that removing scaling from the pipe helped a little as I can play sound for longer period sometime. If there is another test I can do, just ask me. I'll be glad to try it.
I'm also not sure that anyone implemented the timestamps for dv1394src correctly.
So what's the scope of this bug actually? Should we keep it open? If the dv1394src/dvdemux stuff isn't fixed in ubuntu 9.10, you should probably file a separate bug for that (if there isn't one yet).
As far as I could see, some elements do not work well. The question I see is, whether these are issue worth fixing (then this bug should probably be set to NEW) or whether it's not within the scope of GStreamer to fix that (then, this bug shold be WONTFIX or smth similar).
Problems in -good plugins are always worth fixing, but we don't really know what's going on here, or have anything to work with, like a GST_DEBUG log or so. In any case, let's close this bug for now since we haven't had any more comments from he reporter since end 2008. For what it's worth, there was a bug in dv1394src that made it timestamp stuff wrongly and which was only fixed recently, which would have caused issues like those described here. See bug #593910.