[pulseaudio-discuss] Question about writable data

[Tanu Kaskinen]

On Wed, 2015-12-30 at 16:46 +0200, Alexandros Chronopoulos wrote:
> Hi,
> 
> I am using PulseAudio api to implement a scenario which synchronize an
> input stream with  an output stream. Synchronize means that whenever input
> data is available the same number of frames should be set for writing in
> the output.
> 
> In order to achieve that I use two separate streams one for record and the
> other for playback. In the record call back I check the writable size and
> if it is big enough I write the data otherwise I reject the packet. This
> causes some distortion in the output especially when latency is small.
> 
> Trying to overcome this problem I stopped checking for writable data. I use
> pa_stream_begin_write instead before the pa_stream_write to allocated the
> desired data size. This approach seems to work very well even for very
> small latency, even when the reported writable size is zero.
> 
> My question is, if the approach above is safe and what is the actual
> representation of the number returned from pa_stream_writable_size method?

Hmm, I see the documentation for pa_stream_writable_size() is wrong:
"Return the number of bytes that may be written using
pa_stream_write()." The documentation implies that you can't write more
than that, but actually the returned value tells how much the server
has requested from you.

If you write more than the server has requested, the extra amount will
be buffered in a per-stream buffer in the server. The size of the
stream buffer is the maxlength parameter of pa_buffer_attr. The default
maxlength allows you to write a lot to the stream buffer before writes
start to fail.

Writing at the same rate as you read from the capture stream, like you
do, is safe if the sink and the source share the same clock source. If
they use different clocks, however, there will be some clock drift,
which means that either the playback buffer runs empty at some point,
causing a drop-out, or the playback buffer accumulates slowly more and
more data, causing the latency to grow.

-- 
Tanu