[Bug 742141] pulsesink: writeable size will increase bigger than total buffer size if no data feed to pulse.

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=742141
  GStreamer | gst-plugins-good | 1.4.1

--- Comment #5 from Arun Raghavan <arun at accosted.net> 2015-01-09 10:40:38 UTC ---
(In reply to comment #2)
> 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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.