Re: Problems when using osssink in ARM

[Stefan Sauer]

Hi,

there is now a speexresample element in -bad. Maybe that takes less CPU. If the
problem persists, its probably unrelated to the resampler.

Stefan

John Faith schrieb:

> Stefan Kost wrote:
>> hi,
>
> Hi Stefan,
>
>
>> Quoting John Faith:
>>> 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.
>
> I had difficulty in building oprofile against my 2.4 kernel, but I did
> see from ps and top that the 4th fork'ed gst-launch process was using
> all the CPU.  In this pipeline:
> gst-launch filesrc location=file.mp3 ! mad ! audioconvert !
> audioresample ! osssink
>
> , I assume that means the audioresample part (if mad is the 2nd,
> audioconvert is the 3rd).
>
>
>> 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.
>
> I tried adding "filter-length=4", but still have CPU usage at 99% and
> hear nothing.
>
> 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 <[hidden email]> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel