[gst-devel] Audiosink problems for ARM

Stefan Kost ensonic at hora-obscura.de
Fri Sep 28 21:56:36 CEST 2007


Hi,

also try audiotestsrc wave=7 ! ...

wave=7 is sine-table, otherwise it usese float sin(), which on arm without fpu
can be realy slow.

Stefan

Joyious He wrote:
>  Hi Wim,
> 
> Now I trying to make this audio (even video later)working, and I find it
> does a lot of things in osssink using baseaudiosink, audiosink,
> ringbuffer things. Can I get a simple osssink working ?
> 
> I just tried "gst-launch-0.10 audiotestsrc ! filesink
> location="/dev/sound/dsp" " it's working and somehow better than the
> osssink, although still some silence fragment included.
> 
> And how to find where the bottlenecks are ?
> 
> BR
> Joyious
>  
>  
> 
> ÔÚ2007-09-28£¬"Wim Taymans" <wim.taymans at gmail.com> дµÀ£º
> 
>     On Fri, 2007-09-28 at 19:54 +0800, Joyious He wrote:
>     >  
>     >  Hi all,
>     > 
>     > Here I have some questions for gstreamer audiosink:
>     > 
>     > I'm using the osssink on my arm board, and no sound came out
>     > command:gst-launch -v audiotestsrc ! audioconvert ! audioresample !
>     > osssink
>     > 
>     > I checked the source code and the debug info, then find the ringbuffer
>     > writer is some slower than the reader. 
>     > see the debug info:
>     > ......
>     > 0:00:08.656034000 1491 0x3e030 DEBUG baseaudiosink
>     > gstbaseaudiosink.c:848:gst_base_audio_sink_render:<osssink0> align
>     > with prev sample, 25 < 24000
>     > 0:00:08.656789000 1491 0x3e030 DEBUG baseaudiosink
>     > gstbaseaudiosink.c:880:gst_base_audio_sink_render:<osssink0> rendering
>     > at 78822 1024/1024
>     > 0:00:08.657666000 1491 0x3e030 DEBUG ringbuffer
>     > gstringbuffer.c:1362:gst_ring_buffer_commit_full: pointer at 19, write
>     > to 4-26572, diff -15, segtotal 3, segsize 32768
>     > 0:00:08.658613000 1491 0x3e030 DEBUG ringbuffer
>     > gstringbuffer.c:1394:gst_ring_buffer_commit_full:<audiosinkringbuffer0> write @0x4069e008 seg 1, sps 16384, off 26572, avail 2048
>     > 0:00:08.659525000 1491 0x3e030 DEBUG ringbuffer
>     > gstringbuffer.c:1398:gst_ring_buffer_commit_full: copy 2048 bytes
>     > 0:00:08.660592000 1491 0x3e030 DEBUG baseaudiosink
>     > gstbaseaudiosink.c:895:gst_base_audio_sink_render:<osssink0> wrote
>     > 1024 of 1024
>     > 0:00:08.661479000 1491 0x3e030 DEBUG baseaudiosink
>     > gstbaseaudiosink.c:911:gst_base_audio_sink_render:<osssink0> next
>     > sample expected at 79846
>     > 0:00:08.738888000 1491 0x3e030 DEBUG baseaudiosink
>     > gstbaseaudiosink.c:669:gst_base_audio_sink_render:<osssink0> time
>     > 0:00:01.664000000, offset 79872, start 0:00:00.000000000, samples 1024
>     > 0:00:08.740013000 1491 0x3e030 DEBUG baseaudiosink
>     > gstbaseaudiosink.c:738:gst_base_audio_sink_render:<osssink0> running:
>     > start 0:00:01.664000000 - stop 0:00:01.685333333
>     > 0:00:08.741028000 1491 0x3e030 DEBUG baseaudiosink
>     > gstbaseaudiosink.c:743:gst_base_audio_sink_render:<osssink0> base_time
>     > 0:00:00.000000000
>     > 0:00:08.741940000 1491 0x3e030 DEBUG baseaudiosink
>     > gstbaseaudiosink.c:752:gst_base_audio_sink_render:<osssink0>
>     > compensating for latency 0:00:00.000000000
>     > ...... 
>     > since the diff < 0,so the data copying is skipped;
>     > 
>     > I change this behavior to copying the data anyway:
>     > /* segment too far ahead, writer too slow, we need to drop, hopefully
>     > UNLIKELY */
>     > if (G_UNLIKELY (diff < 0)) {
>     > /* we need to drop one segment at a time, pretend we wrote a
>     > * segment. */
>     > // skip = TRUE;
>     > skip = FALSE; //test
>     > break;
>     > }
>     > 
>     > Now the sound comes out,but it's not continous.
>     > 
>     > So I wonder the reason, is my hardware or the ringbuffer thread read
>     > the data faster than my ringbuffer writer ? is this
>     > gst_ring_buffer_prepare_read() keep running without waiting the buffer
>     > writer to input some datas ?
>     > 
>     > As I also saw the design-audiosinks.txt, it says:
>     > A write operation to the ringbuffer will put new samples in the
>     > ringbuffer.
>     > If there is not enough space in the ringbuffer, the write operation
>     > will 
>     > block. The playback of the buffer never stops, even if the buffer is 
>     > empty. When the buffer is empty, silence is played by the device.
>     > 
>     > 
>     > Now how can I solve this problem ? To make the playback wait for the
>     > data writer ? Or to make the data write fast enough ? BTW, the
>     > Gstreamer is taking up almost 99% CPU of my arm board.
>     > 
> 
>     You don't have enough CPU power to play this pipeline in real time. The
>     audiosink will by default not play audio that is too late. I would
>     suggest to optimize the decoders on the board or if it's not the
>     decoders, use a profiler to figure out where the bottlenecks are. 
> 
>     Wim
> 
>     > Hope you can help me to answer these questions.
>     > 
>     > 
>     > Many Thanks,
>     > Joyious
>     >  
>     >  
>     > 
>     > 
>     > 
>     > ______________________________________________________________________
>     > ɱ70ÍòÖÖľÂí²¡¶¾£¬ÈðÐÇ2008°æÃâ·Ñ
>     > -------------------------------------------------------------------------
>     > This SF.net email is sponsored by: Microsoft
>     > Defy all challenges. Microsoft(R) Visual Studio 2005.
>     > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>     > _______________________________________________ gstreamer-devel mailing list gstreamer-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> 
> 
> 
> 
> ------------------------------------------------------------------------
> ɱ70ÍòÖÖľÂí²¡¶¾£¬ÈðÐÇ2008°æÃâ·Ñ
> <http://pro.163.com/event.ng/Type=click&FlightID=96648&AdID=98138&TargetID=635&Values=31,43,51,60,72,82,91,100,110,312,330,332,499,587,702,733,734&Redirect=http://ad.cn.doubleclick.net/clk;134682177;20226578;k%3Fhttp://www.rising.com.cn/2008/trial/index.htm>
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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