[pulseaudio-discuss] Latency of pa_stream_flush

[Tanu Kaskinen]

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.

-- 
Tanu