[pulseaudio-discuss] Gap, silence and latency
csejl at yahoo.com
Mon Mar 12 15:38:36 PDT 2012
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
> > 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
> > 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?
> > 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
> > do not see this. There is a gap between when the movie ends and when it
> > 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
> How long is this audio delay? Is it the same 2-3 seconds that you
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
> > 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.
More information about the pulseaudio-discuss