[pulseaudio-discuss] RTP receiver problem, jumpy samplerate

[Zhang, Vivian]

Erich Boleyn wrote:
> [Ed note:  Just scanned pulseaudio list today after a bit of haitus
>  and noticed a few messages about RTP issues, comments below]
> 
> 
> "Zhang, Vivian" <vivian.zhang at intel.com> wrote:
> 
>> Nickie Deuxyeux wrote:
>>> Hello everyone,
>>> 
>>> I am struggling to make my simple RTP setup work correctly. I have
>>> one sender and one receiver, both running the latest pulseaudio
>>> 0.9.15. Normal "module-native-protocol-tcp" works fine with
>>> pulseaudio client (I am using mplayer to test) running from the
>>> sender side, but when I start the pulseaudio server on the sender
>>> side and start the receiver side, I have the following output:
>> 
>> I also met the same issue on PA 0.9.15,  :(
>> Anyone works fine with rtp module or has some ideas about it?
> 
> 
> I use Pulseaudio and RTP in my home for audio through 5 rooms and
> 7 machines total.
> 
> The current RTP code uses resampling based on instantaneous feedback
> from the buffer levels and assumptions of the current time.  To work
> correctly without continuous audible distortion, it really requires
> the glitch-free mode to be enabled and active on a machine with
> basically no load.  Even then I have found it is troublesome.
> 
> I currently have resampling disabled via a trivial patch, but never
> contributed it to the list because the goal is to fix the resampler
> control algorithm in RTP.  Not being able to run the same remote audio
> on any 2 sets of speakers because they drift apart is really annoying.
> 
> I have a bug opened in the pulseaudio.org bugtracker (#477) at:
>    http://www.pulseaudio.org/ticket/477
> 
> My Wife has let me know it can't persist in this state, and I just got
> a bit of free time to rub together, so the next 2 weekends are
> allocated for working on this and putting a proper debouncing
> algorithm into the resampler control logic in module-rtp-recv. 
> Please check out my comments in the bug ticket and/or email me
> directly if you are interested. 
> 
> Current estimate is that it will be probably next weekend before I
> have 
> a robust fix, but possible that this weekend will do it.
> 
> Unfortunately ahead of that is patching the ALSA 1.0.19 drivers to
> backport the fix which was recently found for the hda-intel
> snd_pcm_avail bug(s). Pulse keeps crashing on the 2 machines with
> hda-intel sound hardware 
> right now, also a wife-friendliness problem.  :-P  None of the patches
> applied cleanly, so I'm having to reverse-engineer the changes between
> 1.0.19 and ALSA git-current.  In any case, I'll post that to this list
> as well when I get it done.

Hi, Erich:
    Thanks for your explanation. Any update for fixing RTP issues? It really blocked some of our works. 
    Or could you send me the trivial patch for "disabling resampling", then we can have a quick fix, thanks a lot.

Thanks.
-- vivian