[gst-devel] Audiosink problems for ARM

[Joyious He]

 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20070928/4e7e1168/attachment.htm>