Recover analyzer DSP and realtime pipeline corrections

TODO.md

@@ -0,0 +1,171 @@
+# Phoenix Analyzer - Soll-/Ist-To-do
+
+## Verbindliches Ziel
+
+- Referenz ist der RTW PortaMonitor 1064X/1064X-PLUS, insbesondere dessen RTA-, PPM-, Peakmeter-, Goniometer- und Korrelationsverhalten.
+- Der primäre RTW-nahe RTA arbeitet als IIR-Fractional-Octave-Filterbank. FFT bleibt eine optionale, getrennt gekennzeichnete Spektrumsansicht.
+- Der RTW-RTA-Modus soll 31 Bänder in 1/3-Oktaven von 20 Hz bis 20 kHz sowie ein Verhalten entsprechend IEC 225/ANSI Class 2 beziehungsweise der passenden aktuellen Nachfolgenorm bieten.
+- Vorgesehene RTA-Modi: Fast, Medium, Slow, Average und Peak; Peak Hold 2,5 s, 4 s oder manuell.
+- Zwischen hörbarem Signal und Anzeige soll nur die unvermeidbare Mess- und Bildschirmlatenz liegen. Alte Messframes dürfen niemals eine anwachsende Verzögerung erzeugen.
+- Normbedingte Ballistiken werden nicht künstlich verkürzt. Technische Transportlatenz und gewollte Instrumententrägheit werden getrennt behandelt.
+- LUFS und LRA bleiben vorerst außerhalb dieser Aufgabenliste.
+
+## Was bereits vorhanden und grundsätzlich brauchbar ist
+
+- Direkte ALSA-Aufnahme mit kleiner Standardperiode von 128 Samples.
+- Ein IIR-RTA ist bereits vorhanden und in Frontend und Backend der Standardmodus.
+- Die 31 RTW-Mittenfrequenzen für 1/3-Oktaven von 20 Hz bis 20 kHz sind bereits hinterlegt.
+- Zusätzlich existieren 1/6- und 1/12-Oktav-Modi als Phoenix-Erweiterungen.
+- RTA-Bandwerte und Peakwerte werden getrennt geführt.
+- DIN-PPM, EBU-PPM, True Peak, VU, RMS, Goniometer, Korrelation, Waveform und Spektrogramm sind grundsätzlich vorhanden.
+- Das Frontend zeichnet mit bis zu 60 Hz und verwendet für Waveform und Spektrogramm teilweise Worker.
+- Konfigurierbare Eingangspegelkorrektur und ein L/R-Laufzeitausgleich existieren.
+
+Diese vorhandenen Funktionen sind nicht automatisch messtechnisch korrekt. Die folgenden Punkte beschreiben den jeweiligen Soll-/Ist-Unterschied.
+
+## Priorität 0 - Anwachsende Anzeigeverzögerung verhindern
+
+- [x] **1. WebSocket auf "latest value wins" umstellen**
+  - **Soll:** Ein langsamer Client erhält immer den neuesten Messzustand; alte Zustände werden verworfen.
+  - **Ist:** Der interne Kanal ist auf 32 Frames begrenzt; der WebSocket sendet im 16-ms-Takt und leert vor jedem Versand bis zum neuesten Zustand. Spektrogrammdaten laufen getrennt.
+  - **Abnahme:** Lokaler Laufzeittest liefert 68 aktuelle Messframes in 1,1 s; alte Zustände werden beim Leeren verworfen.
+
+- [x] **2. Mess-, Visualisierungs- und Konfigurationsdaten trennen**
+  - **Soll:** DSP läuft samplegenau; übertragen wird nur so häufig und so umfangreich wie für die jeweilige Anzeige nötig.
+  - **Ist:** Skalare Messzustände laufen mit etwa 60 JSON-Paketen/s. Spektrogramm sowie Goniometer/Waveform besitzen getrennte, kompakte Binär-WebSockets. Roh-Waveformsamples werden nicht mehr in jedem Capture-Frame vervielfacht; Waveform-Hüllkurven werden beim serverseitigen Leeren lückenlos zusammengeführt. Das doppelte RTA-Bandfeld wurde vollständig entfernt; Konfiguration wird nur separat bei Änderungen synchronisiert.
+  - **Interne Last:** Der Verteiler reicht Messframes als gemeinsam genutzte Referenz weiter. Beim Verwerfen alter Frames werden deshalb keine kompletten Spektrogramm-, XY- und Waveformvektoren mehr kopiert.
+  - **Geprüft:** Protokolltests prüfen Header, Nutzdaten und beschädigte Paketlängen. Ein Servertest stellt sicher, dass große Visualisierungsfelder nicht wieder im JSON-Messstrom landen.
+  - **Abnahme:** Datenwege sind softwareseitig getrennt; die Lastmessung auf der Zielhardware bleibt Bestandteil der End-to-End-Abnahme unter Punkt 17.
+
+- [x] **3. Browser-Verarbeitung auf den neuesten Zustand begrenzen**
+  - **Soll:** Pro Bildschirmframe wird höchstens der neueste vollständige Messzustand verarbeitet.
+  - **Ist:** Der Browser besitzt für Messwerte, Spektrogramm und Visualisierungsdaten jeweils einen Single-Slot-Puffer und verarbeitet höchstens einen aktuellen Zustand pro Animation Frame. Während einer laufenden Verarbeitung ersetzt ein neuer Zustand den wartenden alten. Nicht mehr steigende Sequenznummern werden verworfen.
+  - **Abnahme:** Es existiert kein unbeschränktes Paket- oder Promise-Backlog mehr.
+
+- [x] **3a. Spektrogramm dauerhaft echtzeitfähig machen**
+  - **Ist:** Inkrementelles Spaltenzeichnen statt Vollbild-Neuberechnung, Worker-ACK/Single-Slot, 750-ms-Watchdog mit sauberem Neustart, begrenzter Sprung statt nachträglichem Aufholen sowie eigener Binärstrom mit Quellsequenz.
+  - **Geschwindigkeit:** Feste Zeitbasis von 60 CSS-Pixeln/s bei 1×; 0,5×, 2×, 4× und 6× skalieren exakt und bleiben unabhängig von FFT-Größe und Display-DPI. Gamma und Geschwindigkeit werden global gespeichert.
+  - **Abnahme:** Automatische Tests prüfen alle Geschwindigkeiten, FFT-Größenunabhängigkeit, DPI-Skalierung, Worker-ACK, ausschließlich inkrementelles Hochladen der neuen Bildspalte und 60.000 Spalten als synthetischen Zehn-Minuten-Lauf.
+
+## Priorität 1 - RTW-naher IIR-RTA
+
+- [x] **4. IIR verbindlich als RTW-RTA-Modus behandeln**
+  - **Soll:** RTW-Modus bedeutet eindeutig IIR-Filterbank; FFT ist eine gesonderte Zusatzansicht.
+  - **Ist:** Backend, gespeicherte Konfiguration, Optionsdialog und Laufzeitprofil erzwingen im RTW-Layout jetzt IIR, 31 Dritteloktavbänder, Normalbereich und Filterordnung 6. Alte Browserkonfigurationen können den Motor nicht mehr heimlich auf FFT zurückstellen; das Backend-Paket ist für die Anzeige maßgeblich.
+  - **Geprüft:** Ein automatischer Profiltest prüft sowohl das gesperrte RTW-Profil als auch die weiterhin freie IEC-/Phoenix-Erweiterung.
+  - **Abnahme:** Das RTW-Profil startet reproduzierbar immer mit der validierten IIR-Filterbank.
+
+- [ ] **5. IIR-Filterbank fachgerecht für 31 Dritteloktavbänder auslegen**
+  - **Soll:** 31 Bänder, 20 Hz bis 20 kHz, korrekte Mittenfrequenzen, Bandkanten und Class-2-Toleranzen.
+  - **Ist:** Der RTW-Kern verwendet jetzt je Band einen vollständigen Butterworth-Bandpass sechster Ordnung aus drei unterschiedlichen SOS-Sektionen mit vorverzerrten Bandgrenzen und Normierung auf die Bandmitte. Die Anzeige behält die gerundeten RTW-Nominalwerte, während die Filter mit den exakten IEC-Basis-10-Mitten und -Bandkanten rechnen. Koeffizienten, Zustände und Leistungsrechnung laufen intern in `f64`, damit insbesondere das 20-Hz-Band stabil und genau bleibt.
+  - **Geprüft:** Automatische Frequenzgang- und Zeitbereichstests prüfen alle 31 Mitten, beide -3-dB-Bandkanten, Nachbarbandunterdrückung sowie 44,1, 48 und 96 kHz. A-, C- und Z-Bewertung werden sampleweise vor der Filterbank angewandt und gegen Normformeln geprüft.
+  - **Noch offen:** Der vollständige Class-2-Toleranzmasken-Nachweis und eine formelle Geräte-/Laborvalidierung fehlen; deshalb bleibt der Gesamtpunkt offen.
+  - **Abnahme:** Jedes der 31 Bänder besteht automatisierte Sweep- und Pegeltests innerhalb der festgelegten Toleranzen.
+
+- [ ] **6. RTW-Integrationsmodi vollständig und energetisch korrekt implementieren**
+  - **Soll:** Fast, Medium, Slow, Average und Peak mit dokumentiertem RTW-nahem Verhalten.
+  - **Ist:** Fast, Medium, Slow und Impulse integrieren jetzt blockgrößenunabhängig im Leistungsbereich; Average bildet das kumulative Energiemittel, Peak den höchsten gefilterten Samplewert. Erst danach erfolgt die dB-Umrechnung.
+  - **Geprüft:** Ein Regressionstest bestätigt identische Integration bei unterschiedlichen Blockgrößen.
+  - **Noch offen:** Die gewählte Medium-Zeitkonstante von 0,5 s und die übrigen Profile müssen noch mit vollständigem RTW-Handbuch oder Referenzgerät abgeglichen werden; deshalb bleibt der Gesamtpunkt offen.
+  - **Abnahme:** Sprung-, Burst- und Rauschtests zeigen für jeden Modus reproduzierbares RTW-nahes Verhalten.
+
+- [ ] **7. Peak Hold und Bandspeicher wie beim PortaMonitor ergänzen**
+  - **Soll:** Peak Hold 2,5 s, 4 s oder manuell; Speicher für acht Bänder plus Hold.
+  - **Ist:** Die Anzeige unterstützt jetzt Peak Hold 2,5 s, 4 s und manuell. Der ältere kontinuierliche Backend-Peak sowie der achtbandige RTW-Speicher sind noch nicht vollständig ersetzt beziehungsweise ergänzt.
+  - **Falsch/unvollständig:** Ein kontinuierlich fallender Peak ist funktional nicht dasselbe wie Peak Hold.
+  - **Aufgabe:** Hold-Zeit, manuellen Hold, Reset, Rücklauf nach Hold-Ende und acht auswählbare Speicherbänder implementieren. Aktuellwert und Holdwert visuell eindeutig trennen.
+  - **Abnahme:** Hold-Zeiten und Reset-Verhalten stimmen zeitlich und visuell mit der Referenz überein.
+
+- [ ] **8. RTA-Anzeigeoptionen am PortaMonitor-Profil ausrichten**
+  - **Soll:** 31 Dritteloktavbänder, wählbarer Mess-/Anzeigebereich von 15, 30 oder 45 dB und optionales zweikanaliges Peakmeter.
+  - **Ist:** Mehrere BPO-Modi, RTW-/IEC-Layouts, frei konfigurierte Skalierung und Peak-Overlay sind vorhanden.
+  - **Unstimmig:** Phoenix-Erweiterungen und originale RTW-Funktionen sind nicht getrennt; die Skalen entsprechen nicht zwingend den drei RTW-Bereichen.
+  - **Aufgabe:** Ein gesperrtes RTW-1064X-Profil mit den Originaloptionen anbieten. 1/6 und 1/12 Oktave sowie andere Bereiche ausdrücklich als Phoenix-Erweiterung kennzeichnen.
+  - **Abnahme:** Das RTW-Profil lässt sich direkt anhand des Datenblatts und Referenzgeräts nachvollziehen.
+
+## Priorität 2 - Gemeinsame Messgrundlage
+
+- [x] **9. Tatsächliche ALSA-Parameter verwenden**
+  - **Soll:** Alle Filter, Zeitkonstanten, Frequenzachsen und Aufnahmen verwenden die tatsächlich ausgehandelte Hardwarekonfiguration.
+  - **Ist:** Phoenix liest Rate, Periode und Puffergröße nach der ALSA-Aushandlung zurück. DSP, RTA-Filter, Zeitkonstanten, Aufnahme-Metadaten, Status und Browserfrequenzachse verwenden die tatsächliche Rate; die tatsächliche Periode wird ebenfalls im Messpaket übertragen.
+  - **Geprüft:** RTA-Filtertests laufen bei 44,1, 48 und 96 kHz; die abschließende Prüfung mit real unterschiedlich aushandelnder Hardware bleibt Teil der Geräteabnahme.
+  - **Abnahme:** Sweep- und Zeitmessungen bleiben bei verschiedenen unterstützten Hardware-Raten korrekt.
+
+- [ ] **10. True Peak kontinuierlich und blockübergreifend korrigieren**
+  - **Soll:** Intersample-Peaks werden unabhängig von ihrer Lage zum ALSA-Block zuverlässig erkannt.
+  - **Ist:** Eine 4-fache Sinc-Interpolation mit kurzer Historie existiert.
+  - **Falsch/kaputt:** Ungefähr die letzten acht Intervalle jedes Capture-Blocks werden nicht interpoliert und können zu niedrige dBTP-Werte liefern.
+  - **Aufgabe:** Kontinuierlichen Oversampling-Filter mit vollständiger Historie verwenden und gegen ITU-Testmaterial sowie synthetische Grenzfälle prüfen.
+  - **Abnahme:** Gleiche Peakwerte unabhängig von Blockgrenze, Periodengröße und Samplerate.
+
+- [x] **11. DIN- und EBU-PPM softwareseitig norm- und RTW-nah auslegen**
+  - **Soll:** Richtige Skalen, Referenzpegel, Tonburst-Reaktion, Integration, Rücklauf, Peak Hold, Peak Memory und Over-Anzeige.
+  - **Ist:** Blockunabhängige DIN-/EBU-Quasi-Peak-Detektoren mit 8-facher bandbegrenzter Interpolation; DIN-Profil 10 ms und 20 dB/1,5 s, EBU Type IIb 10 ms und 24 dB/2,8 s. Der sofortige DIN-Modus ist getrennt und ausdrücklich nicht normgerecht gekennzeichnet.
+  - **Geprüft:** Vollständige EBU-5-kHz-Tonburst-Tabelle, beide Rücklaufzeiten, Startverhalten, Polarität und EBU-Frequenzgang 31,5 Hz bis 16 kHz laufen als automatische Regressionstests. Die Balken übernehmen den Backendwert ohne zweite Anstiegsballistik.
+  - **Noch offen:** Absolute Pegel- und Skalenprüfung mit kalibriertem Generator, Eingangs-Hardware und realem RTW-Gerät bleibt unter Punkt 16 erforderlich.
+  - **Abnahme:** Softwaretests bestehen; die endgültige Aussage zur Messgeräte-Konformität erfolgt erst nach der Hardwarevergleichsmessung.
+
+- [ ] **12. VU und RMS eindeutig und reproduzierbar definieren**
+  - **Soll VU:** RTW-artige Moving-Coil-Ballistik mit richtigem Einschwingen, Rücklauf und Überschwingen.
+  - **Ist VU:** 300-ms-Rechteckmittel der gleichgerichteten Samples.
+  - **Falsch VU:** Boxcar-Mittelung entspricht nicht der mechanischen VU-Ballistik.
+  - **Soll RMS:** Dokumentiertes gleitendes Messfenster mit eindeutigem dBFS-/Kalibrierbezug.
+  - **Ist RMS:** RMS nur über den aktuellen ALSA-Block, bei 128 Samples etwa 2,67 ms.
+  - **Falsch RMS:** Wert und Unruhe hängen von der Periodengröße ab.
+  - **Aufgabe:** Beide Detektoren unabhängig von der Capture-Blockgröße implementieren und separat testen.
+  - **Abnahme:** Identische Werte und Ballistiken bei verschiedenen ALSA-Perioden.
+
+- [ ] **13. FFT-Modus als optionale Spektrumsansicht fachlich korrigieren**
+  - **Soll:** FFT ist eine korrekte Zusatzansicht, aber nicht die RTW-IIR-Referenz.
+  - **Ist:** FFT-RTA und Spektrogramm sind vorhanden.
+  - **Falsch:** FFT-Bins werden innerhalb eines Bandes normiert gemittelt statt zur Bandenergie summiert. Rauschsignale und unterschiedlich breite Bänder werden dadurch falsch bewertet.
+  - **Aufgabe:** Binleistungen energetisch integrieren, Fensterleistung korrekt kompensieren und FFT-Ergebnisse gegen die IIR-Referenz testen.
+  - **Abnahme:** Konsistente Pegel bei FFT-Größenwechseln und eindeutig getrennte Kennzeichnung im UI.
+
+## Priorität 3 - Stereoanzeigen und visuelles RTW-Verhalten
+
+- [ ] **14. Goniometer-Datenweg und Persistenz optimieren**
+  - **Soll:** Aktuelle XY-Daten erscheinen im nächsten möglichen Bildschirmframe; Fast/Medium/Slow-Persistenz wirkt wie das RTW-Instrument.
+  - **Ist:** M/S-Darstellung, Gain, AGC, Linien/Punkte und eine 300-ms-Spur sind vorhanden.
+  - **Datenweg erledigt:** XY-Punkte werden mit begrenzter Rate über den eigenen Binärstrom übertragen; JSON-Kopien und unbeschränkte Warteschlangen entfallen.
+  - **Noch offen:** RTW-Persistenzmodi sind nicht verbindlich abgeglichen.
+  - **Aufgabe:** Fast/Medium/Slow-Persistenz am Referenzgerät abstimmen und die vorhandene Ringpufferdarstellung darauf kalibrieren.
+  - **Abnahme:** Geringe Reaktionslatenz ohne unnötige Allokationen, bei vergleichbarem visuellen Nachleuchten.
+
+- [ ] **15. Korrelation vollständig am RTW-Verhalten prüfen**
+  - **Soll:** Bereich -1 bis +1, passende Farben, wählbare Ansprechzeiten von 1,0 s und 2,5 s sowie Negative-Peak-Memory.
+  - **Ist:** Korrelations- und Phasendarstellungen sind grundsätzlich vorhanden.
+  - **Ungeklärt:** Zeitkonstanten, Speicherverhalten und Genauigkeit sind nicht systematisch gegen das PortaMonitor geprüft.
+  - **Aufgabe:** Testsignale für +1, 0 und -1 sowie gleitende Phasenlagen verwenden; Memory und Reset ergänzen beziehungsweise validieren.
+  - **Abnahme:** Statische und dynamische Testsignale stimmen innerhalb der festgelegten Toleranz mit der Referenz überein.
+
+## Priorität 4 - Nachweis und dauerhafte Absicherung
+
+- [ ] **16. RTW-Referenzprofil vervollständigen**
+  - **Soll:** Modell, Firmware, Eingangsart, Skala, Referenzpegel und jedes nachzubildende Preset sind dokumentiert.
+  - **Ist:** Das Datenblatt des 1063X-/1064X-PLUS liegt vor und definiert viele Optionen, aber nicht alle internen Zeitkonstanten und Toleranzdetails.
+  - **Fehlt:** Vollständiges Bedienhandbuch und/oder reale Vergleichsmessungen.
+  - **Aufgabe:** Handbuchdaten und Messprotokolle ergänzen; exakt nachzubildende Funktionen von bewussten Phoenix-Erweiterungen trennen.
+  - **Abnahme:** Jede RTW-nahe Option besitzt eine nachvollziehbare Quelle oder ein Referenzmessprotokoll.
+
+- [ ] **17. End-to-End-Latenz messen und begrenzen**
+  - **Soll:** Bei 60-Hz-Display typisch unter 25 ms zusätzliche Anzeigeverzögerung, normal unter 35 ms; bei 120 Hz möglichst 10 bis 20 ms. Keine anwachsende Warteschlange.
+  - **Ist:** 128-Sample-Capture und 60-Hz-Rendering sind grundsätzlich schnell, aber es gibt keine durchgängige Latenzmessung.
+  - **Fehlt:** Zeitstempel für Capture, DSP, Versand, Browserempfang und tatsächlichen Paint.
+  - **Aufgabe:** Monotone Zeitstempel, Median/P95/Maximum sowie sicht-/hörbaren Impulstest einführen. Instrumentenballistik separat ausweisen.
+  - **Abnahme:** Ziele werden unter realistischer Volllast eingehalten und Regressionen automatisch erkannt.
+
+- [ ] **18. Automatisierte DSP- und Darstellungsregressionstests aufbauen**
+  - **Soll:** Keine Änderung kann unbemerkt Pegel, Frequenzgang, Ballistik, Latenz oder RTW-Darstellung verschlechtern.
+  - **Ist:** DIN-/EBU-PPM, Spektrogramm-Zeitbasis und Langlauf, Worker-Verhalten sowie die Binärprotokolle sind automatisiert abgesichert. Servertests prüfen außerdem das Zusammenführen der Waveform-Hüllkurve und die Trennung großer Nutzdaten vom JSON-Messstrom.
+  - **Noch offen:** Der RTA besitzt nun Tests für alle Bandmitten und -kanten, Nachbarbandunterdrückung, Zeitbereich, A/C/Z, mehrere Sampleraten und blockgrößenunabhängige Integration. True Peak, VU/RMS, Korrelation, reale Periodenvariation und End-to-End-Latenz besitzen noch keine vollständige automatische Regression. Deshalb bleibt dieser Gesamtpunkt offen.
+  - **Aufgabe:** Einzeltöne aller 31 Bänder, Sweeps, Weiß-/Rosarauschen, Pegelsprünge, Tonbursts, Phasen-/Korrelationssignale und Intersample-Peaks testen. Sampleraten, Perioden und Blockgrenzen variieren. RTW-Screenshots und Messprotokolle als Referenz verwenden, soweit rechtlich möglich.
+  - **Abnahme:** Automatischer Bericht mit Erwartungswerten und Toleranzen für jede Messfunktion.
+
+## Empfohlene Bearbeitungsreihenfolge
+
+1. Punkte 1 bis 3: anwachsende Transport- und Browserlatenz beseitigen.
+2. Punkt 9: korrekte gemeinsame Zeit- und Frequenzbasis herstellen.
+3. Punkte 4 bis 8: IIR-RTA als RTW-Kern verbindlich und korrekt auslegen.
+4. Punkte 10 bis 15: weitere Messinstrumente korrigieren und abstimmen.
+5. Punkte 16 bis 18: Referenz, Latenz und Messrichtigkeit dauerhaft nachweisen.