Types for Tracking & Slew

[psionic-k]

lib::audio has a young module that provides AudioTiming, a result of Kalman filtering on audio server ticks to discover the hidden phase. By keeping a jitter-resistant sense of the phase grid, we can estimate a virtual write head that moves continuously. This model erases the phase of the input source and allows dissimilar clock ticks to be related in continuous time.

Downstream, we have other processes that add phase. Even something as simple as whole-pixel read adds a bit of phase. Downstream data is often at a different data rate. Any time we change clocks, we add phase.

The humble, AudioTiming needs to become other kinds of time, adding extra phase, jitter, and converting the data rate.

The filter may be the more valuable piece. Downstream audio pipelines can be timed on the dispatch completion if we measure device timestamps. This is only a little extra work, mainly to harvest the timestamps and generalize the timing filter. The presentation timing definitely needs a kalman filter on it to become useful. Estimating true compositor latch timing requires finding a hidden phase rotation.

Timing is almost always published "best effort." Consumers don't need the latest tick on the grid. The grid itself usually doesn't move fast. Locally, the atomic write head tells us which tick we are nearby. Consumers can use Untorn rather than locking.

Tracking & slew basically means ring buffers. Buffering always boils down to an offset relative to the virtual (continuous interpreted) write head. We can use timing data to decide the goal read index and slew reads toward it. Given that we're almost always using this data with ring buffers and frequently to hand off indexes to the device, it would be good to extend first class support into slang, the slang host-device type agreement checks, and host-side types intended for upload as constants or on host-visible buffers.

Ring buffers. Filtering ticks. Using filtered ticks to track & slew on rings. This is a pretty coherent set of problems that will be found next to each other a lot. Investing in a crate makes sense.

Build or Buy

Not evaluated yet:

• adskalman
• minikalman

Surprisingly, the grid + jitter representations of timing grids are missing. The continuous interpretation is definitely the right one... Where are the crates?

[aidaluciaa]

I like the direction you're describing. Separating tracking from slew makes sense because they solve different timing problems even though they're closely related. A dedicated tracking layer can maintain long-term phase stability, while the slew layer focuses on handling short-term adjustments without introducing unnecessary discontinuities.

I also agree that filtered ticks could become a reusable timing abstraction across different parts of the pipeline instead of remaining tightly coupled to the audio module. If the implementation is generic enough, it could benefit rendering, scheduling, and any component that depends on predictable timing. Building this as a standalone crate also seems like the right long-term approach since other projects could reuse the same primitives.

[psionic-k]

Building this as a standalone crate also seems like the right long-term approach since other projects could reuse the same primitives.

I think so too. I squatted a separate organization to move towards this direction.

The present wait is almost ready to give us the presentation grid. FRR vs VRR detection demonstrates that the filtering probably can't be very generic, but the outputs of filtering are always a clock grid and some variance model that would compose if the user supported some pretty basic APIs.