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

[Luis de Bethencourt]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150109/ee32d053/attachment.html>