[gst-devel] Problems when using osssink in ARM

Stefan Kost ensonic at hora-obscura.de
Thu Oct 4 09:34:25 CEST 2007


hi,

Quoting John Faith <jfaith at freescale.com>:
> Hello,
> 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.

Stefan

>
> Thanks!,
> John
>
>
> 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 ...
>>
>>
>> Thanks,
>> John
>>
>>
>> trimurthulu amaradhi wrote:
>>>  Hi,
>>>
>>>  can you just try with the following
>>>
>>>  gst-launch -v filesrc location=file.mp3 ! mad ! audioconvert
>>> ! osssink sync=false
>>>
>>>  Trimurthulu
>>>
>>>
>>> On 9/29/07, John Faith <jfaith at freescale.com> wrote:
>>>> Hello,
>>>> 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
>>>> zeros?
>>>>
>>>> Thanks!,
>>>> John
>
>
> -------------------------------------------------------------------------
> 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
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>






More information about the gstreamer-devel mailing list