pulsesink: writeable size will increase bigger than total buffer size if no data feed to pulse

[Bing Song]

Our use case is very complex. But the root cause is the writable size will increase to very large if no audio data feed to pulse. Do I need fix the writable size increase or feed audio data at any time to avoid the writable size increase?

One side effect of the writable size increase is buffer will very large for some demux, such as tsdemux. Ts stream should read sequencely. Can read by track. If pulse buffered too many audio data, video pipeline will buffer more data, which will cause consume large memory.

Regards,
Song Bing.

From: gstreamer-devel [mailto:gstreamer-devel-bounces at lists.freedesktop.org] On Behalf Of Luis de Bethencourt
Sent: Friday, January 09, 2015 7:36 PM
To: Discussion of the development of and with GStreamer
Subject: Re: pulsesink: writeable size will increase bigger than total buffer size if no data feed to pulse

Arun replied there.


> In a simple word, the writable size will increase to large value after some

> time if no data feed to pulse. Pulse will consume all audio data as soon as

> send to pulsesink and then audio pipeline will always no data.



Yes, libpulse will continue to ask for more data (until at some point a h/w

underrun occurs). However, if you write out the data when it becomes available,

this should not be a problem.



> Our use case is one AVI clip has large audio PCM sample (one sample has one

> second PCM data). If pulse client buffered all audio data, pulsesink change

> state from PLAYING to PAUSE will fail as no audio data send from demux as demux

> blocked by video pipeline as pulse client buffered too many audio data.

>

> Can we change the behave of pulse client or pulse sink? Or need feed data at

> any time when PLAYING state?



I'm really sorry but I'm having trouble understanding the problem you are

seeing. The audio and video outputs of the demuxer should ideally have a queue

after them so that each of those get their own thread. In that case, one side

having large buffers and the other having small buffers should not matter.



Thanks Arun!

On 9 January 2015 at 10:03, Bing Song <Kevin.Song at freescale.com<mailto:Kevin.Song at freescale.com>> wrote:
Hi,

I report one bug: https://bugzilla.gnome.org/show_bug.cgi?id=742141

But it isn’t a bug, just want ask question.

Is it reasonable below writeable size will increase bigger than total buffer
size if no data feed to pulse?

        pbuf->m_writable = pa_stream_writable_size (pbuf->stream);


Do I need fix writable size increase issue or I need feed data at anytime (send GAP event when no audio data)? Our implement will sent EOS to audio pipeline when backward playback and no audio data feed to pulse.

Regards,
Song Bing.

_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.freedesktop.org<mailto:gstreamer-devel at lists.freedesktop.org>
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150109/c74f6a4f/attachment-0001.html>