Ein Sampler (Teenage Engineering EP-133 K.O. II) an Board A, Kopfhörer an Board B, dazwischen nur Funk. Der Sampler schlägt im Takt, und der Schlag ist im Kopfhörer sofort da. Kein Nachhall, kein Schwimmen. Das Oszilloskop zeigt es: 5,5 ms vom Line-In bis zum Kopfhörer (Median über 20 Schläge, alle zwischen 5,3 und 6,0 ms). Zum Vergleich: Ein Meter Abstand zum Lautsprecher kostet schon 3 ms Schalllaufzeit. Bluetooth-Kopfhörer liegen typisch bei 150 bis 250 ms.
Angefangen haben wir gestern mit Standard-LE-Audio auf zwei nRF5340 Audio DKs, bei 26 ms. Das eigentliche Ziel: Klavier über Funk spielen. Ab etwa 10 ms Ende-zu-Ende merkt man die Verzögerung beim Spielen. So sind wir darunter gekommen:
Der Weg in Zahlen (gemessen am Oszi, Line-In bis Kopfhörer):
| Stand | Latenz |
|---|---|
| LE Audio mit LC3plus, 5-ms-Frames | 26 ms |
| + Flush Timeout 1, Presentation Delay 2 ms, Mono | 17,2 ms (konstant) |
| Bluetooth-ACL-Verbindung mit ADPCM | 8,5 ms (klang aber schlecht) |
| LC3plus über ACL | 10–18 ms, schwankend |
| LC3plus über eigenen 2,4-GHz-Funk, erste Version | 7 ms |
| + Tuning (kleinere I2S-Blöcke, schnellerer Encoder, sofort senden) | 5,5 ms (5,3–6,0) |
Was wir dabei gelernt haben:
LE Audio hat eine harte Untergrenze. Das ISO-Intervall beträgt mindestens 5 ms. Selbst voll ausgereizt (LC3plus mit 5-ms-Frames, ein Übertragungsversuch, 2 ms Presentation Delay) blieben 17,2 ms. Dafür ist LE Audio isochron: Die Latenz schwankt um weniger als 0,05 ms.
Der Codec-Lookahead ist nicht verhandelbar. Bei LC3plus braucht jeder Frame den nächsten: Die Codec-Verzögerung ist zwei Frame-Längen. Mit 1,25-ms-Frames sind das 2,5 ms. Kürzer geht nur mit kürzeren Frames.
Rechenzeit ist Latenz. Der ETSI-Referenzcode von LC3plus war auf dem Cortex-M33 zunächst 2,6-mal zu langsam für Echtzeit. Nach der Optimierung braucht der Encoder 0,9 ms pro Frame statt 3,2 ms, der Decoder 0,4 ms. Die Paketverlust-Verschleierung ging von bis zu 293 ms auf 1,2 ms pro verlorenem Frame zurück. Alles blieb bitgenau bzw. geprüft gegen die Referenz. Die größten Hebel:
- Die Standardbibliothek kopierte Speicher Byte für Byte.
- Die Paketverlust-Verschleierung rechnete Sinus und Cosinus in emulierter Double-Präzision.
- Eine FFT lief über einen generischen Algorithmus.
- Viele Schleifen profitierten von SIMD.
Timing schlägt Bandbreite. Über Bluetooth kamen die Pakete schubweise. Dann braucht der Empfänger einen großen Puffer, und die Latenz wandert. Mit eigenem Funk wird jeder 1,25-ms-Frame gesendet, sobald er codiert ist. Die Pakete kommen im Abstand von höchstens 1,5 ms an, der Puffer im Kopfhörer bleibt bei 1,25 ms.
Schneller rechnen heißt auch: anders runden. Nach 27 Minuten Dauerbetrieb blieb der Sender plötzlich stehen. Ursache war ein Assert im Referenzcode, der sich auf die exakte Rundung von log10 verlässt. Mit -ffast-math rundet der Compiler anders, und bei Musik trifft das irgendwann genau die Grenze. Gefunden per AddressSanitizer-Fuzzing auf dem PC: 24 Millionen Frames in wenigen Minuten, statt stundenlang auf den nächsten Absturz am Board zu warten.
Das Ergebnis: LC3plus mit 1,25-ms-Frames über Enhanced ShockBurst auf dem Netzwerk-Core des nRF5340, ohne Bluetooth. 5,5 ms Ende-zu-Ende, gemessen automatisch per Kreuzkorrelation der beiden Oszi-Kanäle. Fraunhofer nennt für LC3plus mit 1,25-ms-Frames 5 bis 7 ms, abhängig von der Systemimplementierung. Wir liegen am unteren Ende.
Als Nächstes: Stereo, ein noch kleinerer Jitter-Puffer und die Fixed-Point-Variante des Codecs weiter beschleunigen. Die ist bereits von 15,5 auf 3,7 ms pro 2,5-ms-Paket gefallen, bitidentisch zur Referenz.
Entwickelt zusammen mit einem KI-Coding-Assistenten (Claude Code), vom ersten Build bis zur Oszi-Messung.
