In realtime signal work, correct-but-late is simply wrong. The audio callback has a fixed budget, it does not care how busy the machine is, and missing it once is audible.
This is older and less fashionable work than the AI side, and it is where a lot of my instincts about determinism come from.
What that involves
- Deterministic callbacks. No allocation, no locks, no file access and no logging on the realtime thread. The rules are simple and violating any one of them produces intermittent glitches that are miserable to diagnose.
- Lock-free data exchange. Ring buffers and atomics to move data between the realtime thread and everything else without ever blocking the one that cannot wait.
- Filter and effect design. Choosing and implementing filters with the numerical behaviour you need, and knowing when fixed point beats floating point.
- Latency budgets. Measured end to end, including buffers you did not know you had, and reported as worst case rather than average.
- Analysis front ends. Windowing, FFTs and feature extraction, including the pipelines that feed machine learning models on device.
Signals you need this
- Clicks, pops or dropouts that appear only on some machines, or only after an hour.
- Latency that is acceptable on average and unacceptable at the tail.
- A processing chain that works offline and fails in realtime.
- CPU headroom that vanished after a feature landed and nobody knows which one.
How the work runs
Measurement first, on the real target. A scope on a GPIO or a proper realtime trace tells you more in an afternoon than a week of reasoning about the code, and it settles arguments about where the time is going.
Related writing
Start a conversation
Bring the awkward part. If it is not something I should take on I will say so, and point you at what would help.