The motivating problem is modeling the process noise for Vulkan presentation latch and pipewire audio chunk arrival. I'm not only adapting different tick rates but doing things within the ticks, ie at phase offsets. The representations are useful for solving worst-case out-of-phase audio, which can be used to predict an audio buffer goal for a given underrun tolerance.

The coordinates for periodic time can be described with duration + epoch, where the epoch defines alignment of all periods and the anchor for an index. With the coordinates defined, index + phase describes any wall time.

This seems like the kind of problem that would already be done to death, but I don't see a crate that is focused on implementing the basic model. It makes me wonder if I'm doing it wrong or if the name of a popular crate is buried in some other results.

Scheduling within a cycle, at a phase offset, is probably the main reason to want to adopt this kind of time coordinate and to add contracts to prevent likely misuse. Unless someone knows a crate, I guess I will just slop one out and begin identifying problems.

For contracts, I'm mainly leaning towards preventing mixtures of instants and durations from different coordinate systems. While we might modify a timeline (updated inference of phase drift) and the derived quantities for that timeline become out of date, the more egregious kind of errors would be taking a phase offset for one timeline and applying it in another. I would solve this kind of problem by making every Timeline be generic over a unit struct implementing a type for each uniquely paced timeline, preventing the mixture of different coordinate systems. All index-phase and cycles types would then be generic over a specific duration-epoch type and converting them would require the runtime realized timelines.

For more interesting problems, I'm going to be stuffing ML into slack GPU time between frames and the ML will prefer latest audio data, which is processed according to the audio clock rather than the frame clock. If the ML finishes in time, the graphics frame can use it. Pacing these and dealing with their out-of-phase worst cases without presenting underruns is I think representative of a decent industry-useful development case.

If such a crate indeed is missing, seems useful, and could benefit from more / more diverse experience, please get in touch. I'll be publishing the crates under a new organization dedicated to [µTate][GitHub - positron-solutions/MuTate: µTate - MuTating music visualizer - Rust + Vulkan & Slang · GitHub] and its incidentally developed crates. This is part of a broader strategy to enable consumers and businesses to drive development of open source and other technologies that are difficult to develop under one roof.

1 post - 1 participant

Read full topic