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
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
few) underruns happen.
pulseaudio-discuss mailing list