17.02.2018 15:31, Georg Chini пиÑ?еÑ?: > 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. The accumulated latency can be decreased when the writer disconnects. > > 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? > I think we don't need to implement local buffering only to make a correct switching between silence and pipe. Fifo assumes local writer and the buffering should be implemented on it's side if it's necessary for underrun stability. Suspend/resume algorithm will be enough to not confuse source-outputs when no writers connected to pipe. I'll try to reimplement original autosuspend patch to make it more platform-independed. > 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. The writer also should use the CPU too much to write a couple of samples at each iteration. I don't think we need to worry about this in pipe-source module. -- Raman
