[pulseaudio-tickets] [PulseAudio] #477: module-rtp-recv - rtp sink latency is random/playback distorts randomly without glitch-free

[PulseAudio]

#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