Nel realtime, corretto ma in ritardo è semplicemente sbagliato. Il callback audio ha un budget fisso, non gli importa quanto sia occupata la macchina, e mancarlo una volta si sente.
È un lavoro più vecchio e meno di moda della parte AI, ed è da lì che viene buona parte del mio istinto sul determinismo.
Cosa comporta
- Callback deterministici. Niente allocazioni, niente lock, niente accessi a file e niente log sul thread realtime. Le regole sono semplici e violarne una produce glitch intermittenti orribili da diagnosticare.
- Scambio dati lock-free. Ring buffer e atomiche per spostare dati fra il thread realtime e tutto il resto senza mai bloccare quello che non può aspettare.
- Progettazione di filtri ed effetti. Scegliere e implementare filtri con il comportamento numerico che serve, e sapere quando il fixed point batte il floating point.
- Budget di latenza. Misurati end to end, inclusi i buffer che non sapevi di avere, e riportati come caso peggiore, non come media.
- Catena di analisi. Finestratura, FFT ed estrazione di feature, comprese le pipeline che alimentano modelli sul dispositivo.
Quando serve chiamarmi
- Click, pop o dropout che compaiono solo su alcune macchine, o solo dopo un’ora.
- Latenza accettabile in media e inaccettabile nei casi peggiori.
- Una catena che funziona offline e cede in realtime.
- Margine di CPU sparito dopo una feature, e nessuno sa quale.
Come procede il lavoro
Prima la misura, sul target vero. Un oscilloscopio su un GPIO dice in un pomeriggio più di una settimana di ragionamenti sul codice, e chiude le discussioni su dove se ne va il tempo.
Parliamone
Portami il problema spinoso. Se non è un lavoro adatto a me te lo dico, e ti indico chi può aiutarti.