[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]
Regards,
[1] https://github.com/GStreamer/gst-plugins-good/blob/master/ext/pulse/pulsesink.c ,
gst_pulsering_stream_request_cb()
[2] https://github.com/a-darwish/malicious-pulseaudio-clients/blob/master/kill_server_quickly_open_write_streams.c
--
Darwish
http://darwish.chasingpointers.com
More information about the pulseaudio-discuss
mailing list