On Sat, 2011-08-20 at 20:45 +0300, R?mi Denis-Courmont wrote: > Sorry... You could maybe argue that an "underrun" is a general situation > whereby the buffer is lower than it should because the fill speed is slower > than the consumption speed. > > But the libpulse API uses the term "underflow". A buffer underflow is an > _empty_ buffer, not merely a less than optimally filled buffer. Well, when an underflow happens, the stream buffer really is empty. But there are two buffers: the stream buffer and the sink buffer. As long as the data that has been previously moved from the stream buffer to the sink buffer doesn't run out too, glitches are avoidable. Writing to the stream buffer during an underflow causes the written data to be immediately moved to the sink buffer, continuing exactly where the previously written data ended. > > > > Currently an underrun means that there was not enough data in the > > > > stream buffer to satisfy the sink's request when it wanted to fill its > > > > buffer. I'm not saying that the current definition is the best > > > > possible, > > > > > > > > but I don't see anything obviously > > > > wrong in it either. > > > > > > Then I'm sorry for you. Go get yourself an English dictionary. > > > > > > > If VLC assumes that an underrun message means silence/glitch, it's a > > > > bug in VLC, > > > > > > Are you kidding me? Is this that the level of hypocrisy that I should > > > expect when dealing with PulseAudio? > > > > No, I was not kidding. I didn't think I'd be offensive either, but maybe > > I came across as rude. Sorry about that. If the term "underrun" causes > > you to do invalid assumptions about Pulseaudio's internal behavior, then > > the term may be wrong (which you seem to claim), or the documentation > > may be lacking. > > The only way that there could be no glitch is if PulseAudio would do some > black magic to extrapolate the missing samples, in the event of an > "underflow". I don't think this is what happens? Definetely not. I think I explained above how the gliches are avoided when underflows happen. > Anyway. Ignoring underflows is not really an option. When they do _really_ > happen, e.g. due to serious scheduling problems, VLC has to resynchronize the > stream somehow. I don't see any solution other than down-sampling or padding, > or is there? By resynchronizing I guess you mean maintaining A-V sync? I have never been in contact with code that implements A-V sync, so I can't speak very confidently here, but I think the idea is that you can at any time query the current playback latency (fixed hardware latency + currently buffered data) and use this information to schedule the video frames. In case of a "real" underrun, the reported latency stays constant even though you don't send any audio. In other words, the audio stream time stops for the duration of the gap in the audio output. Since the audio time stays stopped, your video frames get delayed accordingly, because they are scheduled using the audio clock instead of the wall clock. I'm not sure how downsampling is relevant here. Is the video being synchronized to the wall clock instead of the audio clock and you need to make the audio stream go faster to catch up with the video stream? If that's the case, don't you run into trouble with the wall clock and the audio clock drifting apart (the sound card most likely doesn't run exactly at 48000 Hz even if it claims to do so)? -- Tanu
