#477: module-rtp-recv - rtp sink latency is random/playback distorts randomly without glitch-free ---------------------------------+------------------------------------------ Reporter: erich | Owner: erich Type: defect | Status: new Priority: high | Milestone: Component: module-rtp-* | Severity: normal Keywords: latency,glitch-free | ---------------------------------+------------------------------------------ When running RTP receiver on ALSA machines without "glitch-free" support, i.e. ones in which the ALSA driver requires the "tched=0" parameter to run, the playback on the sink gets very distorted due to the semi-random latency readings trying to be deduced from the ALSA interfaces.
Examples: It will speed up or slow down (pitch increases or decreases) by as much as 5% to 25+% every 5 seconds during playback, which is quite audible, sometimes creating gaps in playback from reading off the end of the available buffer. Fairly sure the real playback deviation is much much smaller, since when taking out the resampling step, the playback deviates just enough over 10 minutes to hear the echo from another RTP receiver, but otherwise sounds normal. So, so far I've noticed/considered the following: * The readback mechanism being used to determine the latency appears to be partly or completely broken when "glitch-free" is disabled. * Considered using a debouncer to average latency readings over time but it doesn't look like it's just a randomness issue. There may be persistent bias in the values being read, or it could be partly garbage. * I noticed that the code used to match the rate here is rather different from that used by "module-combine". Solution being considered: My favorite idea at the moment is to basically keep track of all samples sent, and perform a long-term (over say a minute each time) drift calculation to see if the buffer is averaging fuller or emptier, then gradually adjust the frequency to compensate. This is an algorithm I used in an audio frequency-matcher before when all I had were semi-reliable buffer fullness levels (before I switched to pulseaudio!), and it worked pretty well. In any case, I'm working on fixing this (hence assigning it to myself), and am testing all the above-listed cases to see which works best. I'm motivated to fix it since I'm using it throughout my house right now, and my wife is annoyed that it's broken! -- Ticket URL: <http://www.pulseaudio.org/ticket/477> PulseAudio <http://pulseaudio.org/> The PulseAudio Sound Server _______________________________________________ pulseaudio-tickets mailing list pulseaudio-tickets@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-tickets