[gst-devel] oss audio pipeline doesn't work when debug on

[Liu, Bin]

The issue got resolved. The video codec accidentally decreased the oss
driver DMA priority. 

-Bin.

-----Original Message-----
From: gstreamer-devel-bounces at lists.sourceforge.net
[mailto:gstreamer-devel-bounces at lists.sourceforge.net] On Behalf Of Liu,
Bin
Sent: Tuesday, June 10, 2008 9:28 AM
To: gstreamer-devel at lists.sourceforge.net
Subject: Re: [gst-devel] oss audio pipeline doesn't work when debug on

Thanks, Dave,

The issue I face is the pipeline can play either the audio or video
stream, but not both together. (The mpeg4 decoder runs on a hardware
similar as a DSP.) The pipeline seems running but no video and audio
outputs.
After a while when I Ctrl+C to stop the pipeline, few video frames will
show on TV. The pipeline I use is 

gst-launch -v --gst-debug-level=2 \
        filesrc location=t.avi ! avidemux name=t  t.audio_00 ! \
        queue ! mad ! osssink  t.video_00 ! \
        queue ! gdecoder Codec=1 ! fbvideosink

Is there any way to give the audio thread higher priority to avoid
dropping samples?
Please let me know if a debug log will give a better idea what is going
on.

Thanks,
-Bin.

-----Original Message-----
From: David Schleef [mailto:ds at schleef.org] 
Sent: Monday, June 09, 2008 8:13 PM
To: Liu, Bin
Cc: gstreamer-devel at lists.sourceforge.net
Subject: Re: [gst-devel] oss audio pipeline doesn't work when debug on

On Mon, Jun 09, 2008 at 03:35:13PM -0500, Liu, Bin wrote:
> Hi,
> 
> I am new to gstreamer. I cross-compiled gst to my ARM board. I have no
> problem to play the mp3 audio stream from a movie clip using the
> following pipeline:
> 
> 	gst-launch -v --gst-debug-level=2 \
>       filesrc location=t.avi ! avidemux ! queue ! mad ! osssink
> 
> But if I turn on the debug level higher than level 2 for any
component,
> I cannot hear anything from the speakers, for example using the
> following pipeline:

This is not surprising.  Audio is automatically dropped when the
buffers arrive at the sink late.  Debugging produces a lot of output,
and if the output device is slow or has a small buffer, it will
likely fill up and cause all GStreamer processing to stop.  On
a desktop system, output to an xterm is both fast and has a large
buffer, so you're unlikely to ever see the problem.  The best way to
solve this on an embedded system is using ssh to log into the system
and/or pipe the debug output out to a file.

It is also possible to write a custom debug handler that manages the
output in a specific way.  For one client, I created a custom debug
handler that emulated a simple web server, and connecting to this
web server gave a constant stream of gstreamer debug output in a
web browser.



dave...


------------------------------------------------------------------------
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel