Dne 27.02.2018 (tor) ob 11:53 +0300 je Raman Shishniou napisal(a): > On 02/26/2018 11:06 PM, Samo PogaÄ?nik wrote: > > > > Dne 26.02.2018 (pon) ob 11:49 +0200 je Tanu Kaskinen napisal(a): > > > > > > On Sat, 2018-02-24 at 17:41 +0100, Samo PogaÄ?nik wrote: > > > > > > > > > > > > Added option auto_drain_pipe_on_resume to enable draining any > > > > remaining > > > > data from the pipe upon every pipe-sink resume out of suspend. > > > > --- > > > > Â src/modules/module-pipe-sink.c | 37 > > > > ++++++++++++++++++++++++++++++++++++- > > > > Â 1 file changed, 36 insertions(+), 1 deletion(-) > > > I didn't review the patch yet, I just wanted to point out that the > > > commit message doesn't explain what problem the patch solves. What's > > > your use case? > > > > > When a pipe reader fails, the pipe sink fills up the pipe and starts > > dropping instead of writing new data. Old data remains in the pipe to > > be consumed by the eventually recovered or replaced reader. By each new > > drop a gap between the pipe content and new data to be written grows. > > If the sink suspends while dropping, resuming from suspend is going to > > clear the pipe and start writing new data into an empty pipe, thus > > removing the gap (old, potentially irrelevant data). > > > > I had also prepared a supplementary change (not yet posted), which > > enables the pipe to auto-leak at the consumers end, whenever a pipe is > > full. When a pipe is full, the size of the unwritten data is first read > > to make room for the repeated write. This way dropping would be > > replaced by leaking and the pipe always contains latest data > > independent of when a real consumer reader get started, stopped or > > replaced, ... However, i am not sure how to preserve content format, > > if necessary. > > > > I thought at some point, that this second change might be sufficient, > > however it makes sense (in terms of pipe content relevance and data > > processing time) to drain the whole pipe upon each resume from suspend. > > > If the pipe reader fails (crashed?), how can the sink be suspended? > Well, i wrote if (or whenever) the sink suspends while dropping because of the pipe being full... and the pipe might get suspended afterwards on behalf of a user pausing the media player. > Why the reader can't just drain the pipe before resume? > The recovered reader probably should drain the pipe before resuming its data processing. It may also happen that the reader would drain out some new data too. The proposed change only makes sure that every pipe-sink resume from suspend makes its first write into an empty pipe. regards, Samo
