Ticket #477 (closed defect: fixed)

Opened 3 years ago

Last modified 12 months ago

module-rtp-recv - rtp sink latency is random/playback distorts randomly without glitch-free

Reported by: erich Owned by: erich
Milestone: Component: module-rtp-*
Keywords: latency,glitch-free Cc: lennart, devnull.pulseaudio@…, mkbosmans@…

Description

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!

Attachments

module-rtp-recv.patch (3.2 kB) - added by mkbosmans 13 months ago.

Change History

  Changed 2 years ago by peitschie

Hi... just wondering if there are any updates on this? I am finding rtp play-back is very erratic.. and am not sure if it could potentially be related to this issue.

  Changed 17 months ago by jw

+1

It still is erratic in 0.9.21 ...

  Changed 17 months ago by jw

  • cc devnull.pulseaudio@… added

follow-up: ↓ 5   Changed 17 months ago by coling

jw, are you using all the patches on stable-queue git branch (which is 0.9.21 + lots of fixes)? There are some rtp related fixes there that fix header parsing that could have previously broken things. Not certainly they'll fix this issue, but all the same it's worth trying.

in reply to: ↑ 4 ; follow-up: ↓ 6   Changed 17 months ago by jw

Replying to coling: You mean commit 678f12d? I will check that out and report afterwards!

in reply to: ↑ 5   Changed 17 months ago by jw

I updated pulseaudio (both sender and receiver), but the speed still changes pretty often and randomly (LAN connection). With vlc on the receiver side it plays normal...

  Changed 13 months ago by mkbosmans

  • cc mkbosmans@… added

Might be the same ticket #670

Changed 13 months ago by mkbosmans

follow-up: ↓ 9   Changed 13 months ago by mkbosmans

Can you confirm that this patch solves the problem?

Obviously the patch is not suitable for inclusion in pulse as is, but it would be nice to have confirmation that the approach used is a right one.

in reply to: ↑ 8 ; follow-up: ↓ 10   Changed 12 months ago by jw

Replying to mkbosmans:

Can you confirm that this patch solves the problem? Obviously the patch is not suitable for inclusion in pulse as is, but it would be nice to have confirmation that the approach used is a right one.

I saw that your patch is included in the current trunk (v1.0-dev-63-gd766b38). If that is the case, congratulations, it solves the problem for me (with a wired connection)! For wireless connections it still has lags, but no speed issues anymore! Thanks a lot!

in reply to: ↑ 9   Changed 12 months ago by jw

Replying to jw: Just wanted to add: lags on wireless connection are only at the beginning, when the playback starts, it is (mostly) lag-free during playback...

  Changed 12 months ago by coling

  • status changed from new to closed
  • resolution set to fixed

I guess we can close this bug then? I'll do that but if there are further issues, feel free to reopen or report new bugs. I'll discuss with Maarten when he's back from playing at sliding down hills as to whether or not we can push this into stable-queue too for better exposure to distro packagers.

Note: See TracTickets for help on using tickets.