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
