[gst-devel] Problems when using osssink in ARM

[John Faith]

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 <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