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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gstreamer-devel




杀70万种木马病毒,瑞星2008版免费