Hi Tanu, Thank you for that help, I think I understand what to do now. > You'll have to adapt to the sound card clock yourself. It would be nice > to allow applications to write samples at their own rate and adapt to > that in pulseaudio, but that hasn't been implemented. Can ask a follow-up question, to check I know how to the soundcard's rate? >From reading the docs, it looks like I should fetch the timing information for the stream, then call pa_timing_info::read_index to find how much of the stream the soundcard has consumed. If there is skew on the soundcard, then that index won't match the number of samples calculated from the elapsed clock_gettime(). I should consider the amount of data buffered to the amount written to the stream beyond "read_index" - so keeping 100ms of samples beyond that should be sufficient to the feed the soundcard regardless of its drift. Is that right? Finally, I couldn't find any discussion of skew in the PulseAudio docs (maybe I was looking for the wrong thing). Perhaps a sentence or paragraph to state that the read position is updated using the soundcard's clock, rather than the system timestamps, might help. Thanks for all your help, Nick Wilson
