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

[Luis de Bethencourt]

I recommend you reply to Arun in the bug thread.

Thanks,
Luis

On 9 January 2015 at 13:00, Bing Song <Kevin.Song at freescale.com> wrote:

>  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> 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
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> 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/7e47a7f4/attachment-0001.html>