[pulseaudio-discuss] Gap, silence and latency

[James Lee]

Tanu Kaskinen <tanuk <at> iki.fi> writes:

> 
> On Sat, 2012-03-10 at 00:11 +0000, James Lee wrote:
> > Hi,
> > 
> > I am working on a small project to integrate pulse into our current ALSA 
system 
> > to mix, re-sample and route audio.  I have a video player on the client side 
> > that takes multicast streams and plays them on "channels."  Each channel 
> > consists of one movie and a streamer on the server side streams the movie 
over 
> > and over again (so the player plays it over and over again).
> 
> Did I understand correctly: there's a server and a client, and the
> server sends multiple video streams to the client? And the client
> machine has the audio and video hardware?

Basically, yes.

> 
> > I have one issue that I just cannot figure out and decided to ask for help 
> > here. I believe this is an issue that is pulse related because without pulse 
I 
> > do not see this.  There is a gap between when the movie ends and when it 
starts  
> > playing again.  It is about 2-3 second gap during which nothing is being 
> > streamed on the channel.
> 
> Is this gap expected or is it a part of the problem?

The gap is expected between replays.  Theoretically, the gap could be much 
larger and the client (player) does not care.

> 
> > And every time this is encountered I see the 
> > following and audio gets out-of-sync (delayed) when the movie starts up 
again:
> 
> How long is this audio delay? Is it the same 2-3 seconds that you
> mentioned?

It is not the same.  I don't have the exact number but it is shorter than the 
gap.  Maybe a second (or less).

> 
> Are audio and video interleaved when they arrive to the client, or are
> they in separate streams? Does the client application create a new
> stream in Pulseaudio when the movie ends and starts again, or is there
> only one stream ever created for each movie channel?
> 

They are interleaved.  It's the same connection to Alsa as long as you stay on 
the same channel.

> > What is the expected behavior here?  Does pulse try to write silence when it 
> > runs into a complete underrun (0 bytes in queue)?  Even then, why would 
there 
> > be a delay in audio?  It almost looks like pulse is writing too much or at 
> > least more than it should during this gap?
> 
> There are two kinds of underruns: alsa underruns and stream underruns.
> This log snippet shows both happening. Alsa underruns should ideally
> never happen, and realtime scheduling is used to try to make sure that
> we can always fill the hardware buffers in time. It seems like you have
> disabled realtime scheduling. That's not recommended. When an alsa
> underrun happens, that will cause a delay.

I see stream underruns all the time and it never causes an issue.  As for the 
Alsa underrun, this is the only time that I see it when a movie replays with a 
gap in between.  The realtime scheduling was disabled because I was running 
pulse in system mode (see bug #639211). The client is an embedded device.

I just ran pulse in non-system mode with realtime scheduling enabled and it 
still runs into the Alsa underrun (Underrun on 'ALSA Playback', 0 bytes in 
queue).  Anything else I can try or provide for you to look at?

> 
> Stream underruns happen when the client isn't writing data fast enough
> to fulfill the requests from the hardware. Pulseaudio writes silence to
> the hardware during these underruns, which will cause delay if the
> underrun lasts for long enough. The stream underruns don't always
> translate into gaps and delays, because if more data arrives quickly
> enough after the underrun, the silence that was written to the hardware
> buffer will be overwritten with the real data. "Requesting rewind due to
> end of underrun" is printed when new data is received during a stream
> underrun. "Rewind" means here rewriting as much as possible of the
> silence in the hardware buffer.
> 
> Regardless of any delays due to the underruns, Pulseaudio will report
> the current latency to the client, and that latency information should
> be used to synchronize the video playback with audio. If things get
> permanently out-of-sync, then either the video player isn't using this
> information properly, or the alsa driver is acting funny, leading to
> incorrect latency information.
> 

Thanks a lot for your help on this.