[pulseaudio-discuss] Issue migrating to pulseaudio8.0: Audio streamed through gsteamer pulsesink pulgin starts to play delayed

Ahmed S. Darwish darwish.07 at gmail.com
Sat Nov 26 09:56:40 UTC 2016

On Fri, Nov 25, 2016 at 10:56:55AM +0000, Mahendran, Dandapani (D.) wrote:
> Hello Darwish,
> Thank you for your response.
> I have attached the gst & pulseaudio logs with time stamps.
> Audio is played with delay and breaks/cut.
> Also, attaching the pulseaudio log taken by running "extended-test.c", that
> streams the audio through same sink (route_andautonav).  During this testing with
> extended-test.c, audio is streamed properly without any delay/break/cut.  So the
> problem seems more oriented towards gstreamer and pulsesink plugin.

Yeah, from the gstreamer log there's a lot of instances of:

  0:02:42.130359686 gst_pulsering_stream_request_cb: got request for length 17640
  0:02:42.130592686 gst_pulsering_stream_underflow_cb: Got underflow
  0:02:51.930305021 gst_pulsering_stream_request_cb: got request for length 9526
  0:02:51.930489354 gst_pulsering_stream_underflow_cb: Got underflow
  0:02:54.775065355 gst_pulsering_stream_request_cb: got request for length 9702
  0:02:54.775288355 gst_pulsering_stream_underflow_cb: Got underflow

So pulse _is doing its job_ and asks for the stream to be filled
through the stream's write callback. Meanwhile gstreamer does not
provide it anything in return -- triggering an underrun.

So the question is, why gstreamer is not fulfilling the requests?

Looking at gstreamer's pulsesink code [1], it seems the stream
write callback only fulfills the request and signals the PA
mainloop if there's an in-commit buffer with appropriate length.

So either there's a bug in the sink's handling of the mainloop, or
the gstreamer source is not providing audio at appropriate speed.

PS. The attached "extended-test.c" coding is misusing pulse's
stream underflow and stream ready callbacks. Check pacat source
code for the more appropriate handling.

PSS. From the attached pulse logs, you're creating a BIG number of
streams at once. This triggers __a lot of__ rewinds for existing
streams playing audio and increases the the possibility of cracks
and server misbehavior [2]


[1] https://github.com/GStreamer/gst-plugins-good/blob/master/ext/pulse/pulsesink.c ,

[2] https://github.com/a-darwish/malicious-pulseaudio-clients/blob/master/kill_server_quickly_open_write_streams.c


More information about the pulseaudio-discuss mailing list