On Mon, 2012-03-12 at 22:38 +0000, James Lee wrote:
> Tanu Kaskinen <tanuk <at> iki.fi> writes:
> > 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.
What happens during this gap? I guess the stream from the server has a
gap, i.e. it doesn't send silence. Does the client generate silence to
Pulseaudio during this time, or does it just stop writing data?
> > > 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.
(What bug tracker are you referring to?)
> 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?
There seems to be some confusion about what is a stream underrun and
what is an alsa underrun. My fault, sorry for not giving advice on how
to distinguish them in Pulseaudio logs. "Underrun on 'ALSA Playback', 0
bytes in queue" is a stream underrun ("ALSA Playback" is the name of
your stream - all programs that use Pulseaudio through the alsa plugin
get that name). "alsa-sink.c: Underrun!" is an alsa underrun.
The stream underrun is expected even with realtime scheduling if you
stop sending data during the gap. One thing that I didn't understand: if
you thought that the "Underrun on 'ALSA Playback'" message indicated an
alsa underrun, what did you mean when you said that you "see stream
underruns all the time and it never causes an issue"? What exactly are
you seeing?
--
Tanu
