Source and sinks that share the same clock source are those found in the same sound card, right? Which are the options if this is not the case, if for example I use a USB mic with my system speakers? Is there any way to prevent the process from clock driff? On Wed, Dec 30, 2015 at 5:01 PM, Tanu Kaskinen <tanuk at iki.fi> wrote: > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20151231/9e437916/attachment.html>
