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.
