Hi, Thanks for the reply. On 07/16/2013 03:28 PM, Tanu Kaskinen wrote: > On Tue, 2013-07-16 at 14:41 +0300, Tanu Kaskinen wrote: >> >> 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. With PA_SEEK_ABSOLUTE offset 0, the sink seems to be getting rewound but the first N seconds of the new sound (depending on how much you had written before) now gets thrown away. The write callback gets called continuously until it has caught up with the read position. I also tried PA_SEEK_RELATIVE_ON_READ with a negative offset corresponding to around the 100ms latency and this seems to work. However if I go too far back the first samples of the sound gets discarded here as well... So it seems the only decent way to get the behaviour I want is to simply disconnect and reconnect. I guess it makes sense in a way because the new data really is a new stream of data without a fixed time relation to the existing stream. I just thought it could cause some unnecessary roundtrips to the server... Regards, Magnus
