[pulseaudio-discuss] Latency of pa_stream_flush

[Magnus Hjorth]

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?

I could work around this by using the disconnect/reconnect stream 
method, or by lowering the latency of the stream, but neither of those 
seem like optimal solutions to me.

Regards,
Magnus