rtp sink latency increments

[Rudd-O]

For some reason, my paprefs-configured RTP Multicast Sink grows in latency as the day goes on. The only way to solve it is to close all apps using the PA daemon, so that the PA daemon auto closes as well.

Here's the current latency: 2695098 usec

Here's the latency of a client stream started a few moments ago: 3513671 μs (= buffer: 818730 μs + sink: 2694941 μs)

This kind of latency is making playback of YouTube? videos impossible -- unless I manually stop using the RTP sink by changing the server address in paprefs to one of my PulseAudio servers beforehand.

Why the latency?

[lennart]

Right now the RTP sink does not deal with deviating quartzes, Due to that you are experiencing the increasing latencies. To fix this is on my TODO list.

Also note, that RTP is not really suitable to synchonize video and audio on different hosts. i.e. you cannot play a video on machine A and have synchronous audio playback on machine B when using RTP.

[bcavagnolo]

Hello,

My company has been using pulseaudio in mesh networking demos. Recently, we had the same problem described here. We observed both gradual and abrupt increases in latency. Here's what was going on:

Suppose the recv module's memblockq can hold 5 seconds of audio for a given stream. The rtp recv module is set up to prebuffer 100ms of audio. If the module fails to receive 2 seconds worth of packets starting at t=0, the 100ms will be consumed, the length of the recv module's memblockq will go to 0, and the sink will output silence until t=2 seconds. When the next packet successfully arrives at t=2 seconds, the recv module will seek forward 2 seconds in the queue and insert the new packet. This leaves 2 seconds of silence at the beginning of the queue. The sink will play this silence before getting to the new packet. So, the sink will play 2 seconds of silence while the memblockq is empty, and another 2 seconds of silence after the t=2 packet arrives, and it will finally play the t=2 packet at t=4s.

On the other hand, if the memblockq can only hold 500ms of audio, when it attempts to seek forward the 2 seconds, it will fail and purge the queue. In this case, the t=2 packet will be played as soon as possible, which will be approximately correct.

The fix for this problem is to specify the size of the memblockq in time instead of bytes. When the rtp session is created, the size of the memblockq is calculated based on the sample spec. I've attached a patch against today's svn HEAD.

[lennart]

The git version of the rtp code now can deal with deviating quartzes and resamples if necessary.