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
