On 17.02.2018 22:05, Raman Shuishniou wrote: > 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. >>>>>>> --- >>>>>> >>>> > >> >> 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. OK. > >> 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. > > If the writer writes larger chunks of data to the pipe, the calculation of the latency should be reconsidered. Currently it returns the amount of data in the pipe. This means, the latency will remain constant for some time and then suddenly jump up, when the next block is written. Would it not be better to return the time since the last pipe read as latency? You can actually test what is better by observing the end-to-end latency that module-loopback reports. The numbers should not vary too much after a minute of runtime - around +/-500 usec is a normal value if you set adjust_time=1. If you are seeing jumps of several ms, the source does not report latency correctly.
