Tanu Kaskinen <tanuk <at> iki.fi> writes: > > 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? > Nothing happens during this gap. The server does not send silence. The client simply stops writing data. > > (What bug tracker are you referring to?) > Sorry. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639211 > > 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? > Ok, it sounds like I had them backwards then. I see the following all the time: I: [alsa-sink] alsa-sink.c: Underrun! and there is no audio delay. Only audio delay I encounter is when I see a stream underrun (Underrun on 'ALSA Playback', 0 bytes in queue). And it only happens after the gap. Keep in mind that just going through ALSA without pulse does not produce this delay. You mentioned pulse providing latency information, does the client have to do something different (according to the feedback) now that pulse has been put in place?
