Sorry for the late reply. On Thu, 2017-09-21 at 15:52 +0000, Nicholas Wilson wrote: > 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? The sound card may read samples in bigger chunks than 100 ms. Is there a problem with letting pulseaudio schedule your writes? That is, write the requested amount whenever the write callback gets called. > 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. Good idea. I think at least pa_stream_get_time(), pa_stream_get_latency() and the pa_timing_info struct description should mention that the time values are in the sound card clock domain. Do you think it would be good to repeat it also for each individual member of pa_timing_info? -- Tanu https://www.patreon.com/tanuk
