[pulseaudio-discuss] Handling audio skew during playback

[Tanu Kaskinen]

On Wed, 2017-09-20 at 17:00 +0000, Nicholas Wilson wrote:
> Hi,
> 
> I have a question about how PulseAudio expects skew to be handled
> during playback.
> 
> When you make a stream running at 48kHz, does it consume samples at
> 48kHz as measured by the OS clock (clock_gettime) or as measured by
> the soundcard's clock?

As measured by the sound card's clock.

> Suppose that I have a 24-hour audio stream, which has 24 * 3600 *
> 48000 = 4147200000 samples. It's common for crystal oscillators to
> have a small inaccuracy (eg 50 parts per million), which is a four-
> second error after 24 hours.
> 
> I'm playing back using PulseAudio's stream API in "push mode",
> writing data to the PulseAudio stream as it arrives over the network,
> using pa_stream_write, with enough buffering to ensure no underruns.
> 
> If the soundcard has 50ppm error, then after 24 hours it could
> potentially have consumed 4147407360 samples, ie 207360 samples or 4
> seconds' worth of extra samples which have to come from somewhere! Or
> we could have overflowed the stream's buffer by that much if the
> soundcard is running slowly.
> 
> I could regulate the received audio data against
> clock_gettime(CLOCK_MONOTONIC), which is the same timing source that
> PulseAudio uses internally, such that after 24 hours have elapsed
> (according to that clock), I have fed in 24-hours exactly of samples.
>  Is that enough to satisfy PulseAudio, or do I potentially to stuff
> in extra samples if the soundcard is running fast (and drop samples
> if the soundcard is running slow)?

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.

Note that even if pulseaudio used the system clock, you would still
have this problem, unless the sender over the network generates samples
in sync with your system clock. (Oh, I should have read the rest of the
message before starting my reply. Apparently you already have code for
syncing with the system clock.)

module-null-sink creates a sink that should run in sync with the system
clock, so you could load a null sink, play to it from your application
and use module-loopback to connect the null sink's monitor source to
the hardware sink. But probably it's best if you adapt to the sound
card clock inside your application.

-- 
Tanu

https://www.patreon.com/tanuk