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.
