GNOME Bugzilla – Bug 788529
pulsesink: playing after EOS causes a gap in playback after seek
Last modified: 2018-11-03 15:22:47 UTC
Created attachment 360920 [details] Scenario file for gst-validate If after EOS playing state of pipeline is maintain, PulseAudio still wants to render client's data and calls request callback. pulsesink doesn't have data to write, thus PulseAudio render "silence". If after some waiting time (e.g. 30 seconds), GStreamer's client seeks (e.g. to 0), a user will hear proper playback for a while (e.g. 12 seconds), than "silence" will be rendered by PulseAudio till stream time doesn't reach waiting time (earlier mentioned 30 seconds). To reproduce, please run command with attached scenario file: gst-validate-1.0 --set-scenario=brainson.scenario uridecodebin uri=https://play.podtrac.com/APM-BrainsOn/play.publicradio.org/itunes/d/podcast/minnesota/podcasts/brains_on/2017/02/brainson_20170214_69_20170214_64.mp3 ! autoaudiosink It seems that: - pulsesink calculates absolute offset in PulseAudio's client buffer based on running (?) time, - PulseAudio doesn't increase write index, when silence is rendered (samples for silence are stored in separate memory block), i.e. underrun is happened, - PulseAudio doesn't correct write index, if data are provided after silence, - PulseAudio increases read index during silence. IMHO pulsesink expects that PulseSink' read index should not be increased or write index will be rewind to position of read index after underrun.
I reported a problem in PulseAudio's bugtracker: https://bugs.freedesktop.org/show_bug.cgi?id=103103, because it is possible that the problem can have a source in PulseAudio. What is missing in my bug report here (I can't edit it) is a fact, that pulsesink is blocked due to lack of space in client buffer and woken after almost 30 seconds - pulsesink very quickly provides data for ~12 seconds of playback than PulseAudio generates 18 seconds of silence. Values 12 and 18 can vary for attached scenario, but can sum up to 30 seconds (e.g. 9/21 etc.).
It is currently confirmed that the problem lays in PulseAudio - https://bugs.freedesktop.org/show_bug.cgi?id=103103#c16. Thus from GStreamer's point of view it is not a bug, but I want to keep the report open to be able add information, which version of PulseAudio will fix the problem.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/409.