On 17.02.2018 11:08, Raman Shuishniou wrote: > 16.02.2018 23:50, Georg Chini пиÑ?еÑ?: >> On 16.02.2018 17:37, Raman Shishniou wrote: >>> >>> On 02/16/2018 12:00 PM, Georg Chini wrote: >>>> On 14.02.2018 23:16, Raman Shyshniou wrote: >>>>> Currently the pipe-source does not produce any data if no >>>>> writer is connected. This patch enable silence generator >>>>> when last writer closed pipe. It will stop automatically >>>>> when any data appears. >>>>> --- >>>> >> >> I agree that the timer can be disabled and that the time stamp >> gets meaningless the way it is set now when reading from the >> pipe. But we must continue without interruption when we switch >> from pipe to silence, so we should set the time stamp to >> something meaningful before switching to silence. (Switching >> between pipe and silence properly would not have worked with >> my code above.) > > Switching from pipe to silence can be easily done by generation a > little less silence in first iteration. Yes, that is what the pseudo code is doing. > It's not working when switching from silence to pipe. > > Actually we don't know if the writer can buffer data and/or trying to > do some congession control. When the pipe have some data - source must > read and post it immediately. > > While switching from silence to pipe we can wait until we run out of > silence, but pipe has data to post right here and right now. For > example, if the latency is 20ms and we wait for 10ms before starting > the first read, the writer will just write more data to pipe while we > waiting (+10ms). We will read and post that extra data on the next > iteration. > > So we need to drop extra data from pipe or buffer the head of data > each iteration. Both solutions are bad. I think we'll just give the > source-output(s) a chance to deal with the extra silence we generated. You are (again) right, waiting for the silence to be played only moves the problem to the first pipe read. What happens when pipe data is coming in is that the latency (as seen by the source output) suddenly jumps up by possibly as much as one full source latency. If the receiving side does not compensate somehow (like module-loopback does), switching between pipe and silence multiple times will lead to accumulated latency. Therefore I do not think it is acceptable to hope that the source-output can deal with the extra silence. To me it appears like the only correct solution is to implement some local buffering, so that we can rewind the source and drop the remaining silence when pipe data comes in. It looks rather difficult to implement silence generation correctly, maybe we should drop the whole idea and stick with your original suspend/unsuspend approach. Implementing some local buffering would however increase underrun stability (at least when used with module-loopback). What do you think? One more point I have been thinking about: The pipe sets POLLIN as soon as data is available, which means we will possibly run an iteration of the thread function every couple of samples, leading to high CPU load, depending on the way the writer delivers the data. It could be changed to a timer based approach - there are the pa_smoother functions which account for the difference between system clock and writer clock. (See for example the alsa-sink code, there we have a similar situation.) So if we stick to the idea of generating silence, it might be worth considering a timer based approach.
