On 15.02.2018 10:31, Raman Shishniou wrote:
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.
How about a max_latency_msec argument in the sense that the logic
will not be completely disabled, but module-loopback will not try to
increase the latency above max_latency_msec (if specified) even if
underruns occur?
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
