#1540·snapcast

[Server] Accepting audio from asynchronous (non-monotonic) sources

Author: CirrusNeptuneCreated Jul 11, 2026Updated Jul 11, 2026

For Pipewire in particular, the audio graph is scheduled according to the node with the lowest priority.driver value. For Wireplumber users, this is usually the default ALSA output device as long as it is active in the graph. In this case, the clock source comes from the device’s own clock, which may considerably drift from the system’s monotonic clock.

I have a pretty cheap audio interface which runs about 0.01% faster than the monotonic clock. Therefore, excess samples are received by snapserver, causing the chunk timestamps to outrun the monotonic clock. Eventually, chunks appear to come from the future and force clients into an endless discard loop.

I can think of three solutions:

  1. Employ a similar timing correction mechanism on the server as the client (sample duplication / removal). This is somewhat ugly because latency would need to be introduced to calculate average monotonic time errors. It’s also somewhat fragile to discontinuity scenarios.
  2. Report server clock to clients using the device clock instead. This would be a good low-latency solution but is probably impossible for non-local stream sources (e.g. tcp).
  3. External clocking? Perhaps with a central PTP server. Sources would be expected send samples to snapserver regulated by this clock source, and players would use this instead of the snapserver time.

Ideally the best of the three would be selected depending on the user’s scenario.

Steps to Reproduce

  1. Provide snapserver with a source that runs slightly faster than 48kHz on the monotonic clock

Environment details

  • OS: NixOS 26.05
  • Snapcast version 0.35.0
  • Installed from a package