[gst-devel] Problems when using osssink in ARM
ensonic at hora-obscura.de
Thu Oct 4 09:34:25 CEST 2007
Quoting John Faith <jfaith at freescale.com>:
> To follow up on my own post, I found that (as someone else found with
> another ARM board) that this problem seems to be due to a lack of CPU
> cycles. If I simplify the pipeline by using a .wav file with the same
> frequency which osssink wants (8kHz in my case), then the sound file
> plays fine and CPU usage is about 5% versus 99% using "mad !
> audioconvert ! audioresample".
> gst-launch filesrc location=file-8k.wav ! wavparse ! osssink
> This makes me wonder if there is any way to cause an error/exit if a
> pipeline is out of realtime. It would be nice if an application using
> gstreamer could tell the user what is happening instead of just
> delivering silence.
Can you run oprofile (it runs on arm). My guess its audioresample.
Unfortunately we don't do qos for audio. If we would audio-resample
could switch to a simple algorithm on high qos-ration to save cycles.
Can you try " audioresample filter-length=4 " and look at the cpu
usage. this will probably not good quality wise, but help to see if it
is the filter in the resampler.
> John Faith wrote:
>> Hi Trimurthulu,
>> Thanks for the suggestion.
>> With the 'sync=false', I still get mostly zeros for the data buffer, but
>> now about every 2.5 seconds, I get a short (~.2s) burst of noise and the
>> data buffer for the burst is mostly 0xFFs.
>> I assume I need the audioresample, since without it, I get:
>> ERROR: from element /pipeline0/filesrc0: Internal data flow error.
>> Additional debug info:
>> gstbasesrc.c(1642): gst_base_src_loop (): /pipeline0/filesrc0:
>> streaming task paused, reason not-negotiated (-4)
>> ERROR: pipeline doesn't want to preroll."
>> Setting pipeline to NULL ...
>> FREEING pipeline ...
>> trimurthulu amaradhi wrote:
>>> can you just try with the following
>>> gst-launch -v filesrc location=file.mp3 ! mad ! audioconvert
>>> ! osssink sync=false
>>> On 9/29/07, John Faith <jfaith at freescale.com> wrote:
>>>> I am seeing the same problem as is described earlier in this thread.
>>>> When I use 'gst-launch -v filesrc location=file.mp3 ! mad ! audioconvert
>>>> ! osssink', I get silence like the original poster.
>>>> I have verified that madplay works on my ARM board, and I have heard the
>>>> short sample tone using 'gst-launch audiotestsrc ! audioconvert !
>>>> audioresample ! osssink', so I assume the hardware, OSS driver, and
>>>> gstreamer are mostly working.
>>>> As an experiemnt, I used filesink instead of osssink, and used an OSS
>>>> utility to play the raw audio data. This also produced sound.
>>>> Then I put printf()s in gst-plugins-good-0.10.5/sys/oss/gstosssink.c to
>>>> print out the first 10 bytes of the data passed to gst_oss_sink_write()
>>>> and saw only zeros, which explains the silence.
>>>> Has anyone been able to solve this problem or could advise on other
>>>> debug methods? I have used --gst-debug-level, but I am not sure what to
>>>> look for.
>>>> If I replace filesink with osssink, what might cause the data to be all
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
More information about the gstreamer-devel