[pulseaudio-discuss] Latency of pa_stream_flush

[Magnus Hjorth]

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