On 02/15/2018 10:20 AM, Georg Chini wrote: > On 14.02.2018 22:51, Raman Shishniou wrote: >> On 02/14/2018 07:20 PM, Georg Chini wrote: >>> On 14.02.2018 15:25, Raman Shyshniou wrote: >>>> This patch adds a underrun_protection argument to >>>> control underrun protection algorithm. Disabling >>>> protection will keep loopback latency regardless >>>> of underruns. >>> Again I do not understand the motivation of the patch. >>> In what situations are you seeing so many underruns and >>> still want to keep the original configured latency value? >>> Audio will be very bad in that case. >>> >> All situations where where latency is more important than data integrity. >> Voice over IP (telephony) for example, receiving audio data using network >> by UDP/RTP. Any data loss leads to underruns in loopback module. > > This is not correct. It will only lead to underruns, if module-loopback runs > out of data. So if you buffer enough data, missing packets in the voice > stream would just appear to be small sample rate variations from the > perspective of the loopback module. Because the loopback module > does some adaptive re-sampling, these variations are no problem. > > Maybe this happens for you because module-pipe-source has no buffer > at all and simply passes the values through whenever data arrives. > With missing data packets, this can surely lead to underruns on the > source side which are passed on to the loopback module. > Perhaps you should implement some buffering in pipe-source? > > I don't see the point of your change. If you are seeing massive underruns, > audio quality will be really bad and just sticking to the configured latency > will not improve the situation. For me, the permanent occurrence of > underruns shows that there is something wrong with your setup in the first > place. The better idea is to correct the audio chain, so that no (or only very > few) underruns happen. I Agree. For live streaming or internet radio I can buffer more data up to several seconds (or just use tcp). But not for telephony, where 10-20 underruns per hour is acceptable, but latency more than 50-100ms is not. Loopback module increases latency permanently. There is no way to decrease it without unload and load again.
