[pulseaudio-discuss] Latency of pa_stream_flush

[Tanu Kaskinen]

On Tue, 2013-07-16 at 14:41 +0300, Tanu Kaskinen wrote:
> On Tue, 2013-07-16 at 12:26 +0200, Magnus Hjorth wrote:
> > Hi list,
> > 
> > While I was working a little on the PulseAudio support in my sound file 
> > editor, I noticed something a bit funny. It seems that disconnecting a 
> > playback stream and then reconnecting it again gives much lower latency 
> > for me than either calling pa_stream_flush on the stream or calling 
> > pa_stream_write with PA_SEEK_RELATIVE_ON_READ. The two latter methods 
> > seem to be dependent on which latency is configured for the stream, 
> > while disconnecting seems to be independent of this.
> > 
> > I made a little test program  to demonstrate. With it, you can test the 
> > different methods by pressing the number keys. Source is here: 
> > http://codepad.org/BjWZOgx1
> > 
> > What I'm using this for is when playing back sound and the user wants to 
> > jump to another part of the file in the middle of playback. I just want 
> > to stop the current playback and start the new as quickly as possible. 
> > For this use case I also don't care or need to know exactly where the 
> > old playback stops and it's also acceptable with a little gap/silence 
> > between the old and new sound.
> > 
> > I can understand the relative_on_read method has an implicit guarantee 
> > of gaplessness since you (from the client's point of view) overwrite in 
> > the middle of a buffer to which you have already written,  but I don't 
> > see why pa_stream_flush has to provide such a guarantee. I would rather 
> > expect the flush function to provide the fastest possible method of 
> > flushing, which it doesn't seem to do.
> > 
> > Is this intended behavior of pa_stream_flush? If so, would it be 
> > possible to add another call "pa_stream_reset" or such that does the 
> > equivalent of disconnect + connect?
> 
> The documentation of pa_stream_flush() says: "Flush the playback buffer
> of this stream." That's indeed everything that pa_stream_flush() does,
> it doesn't touch the sink buffer (which is what creating a new stream
> does). So, any audio that has already moved from the stream buffer to
> the sink buffer will play before any new audio that you write after the
> flush.
> 
> It would probably make sense to rewrite the sink buffer on stream flush.
> This would achieve the same latency as creating a new stream.

You could also try PA_SEEK_ABSOLUTE. If you give 0 as the offset,
meaning that you try to return to the very beginning of the stream
(which is of course impossible), I guess the result will be that the
sink buffer gets rewound as much as possible.

-- 
Tanu