# Phoenix Analyzer - Soll-/Ist-To-do ## Verbindliches Ziel - Referenz ist der RTW PortaMonitor 1064X/1064X-PLUS, insbesondere dessen RTA-, PPM-, Peakmeter-, Goniometer- und Korrelationsverhalten. - Gemessen werden analoge Line-Signale. Deshalb umfasst die endgültige Referenzmessung immer den vollständigen analogen Eingang einschließlich Vorstufe, Antialiasing und A/D-Wandler; reine Digitaltests sichern nur den nachfolgenden DSP ab. - 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-Detektoren: Average (RMS) und Peak (10 ms); dazu die RMS-Reaktionszeiten Fast, Medium, Slow und Impulse sowie 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 DSP läuft weiterhin samplekontinuierlich, erzeugt skalare Transport-Snapshots aber periodengrößenunabhängig nur noch mit im Mittel 60 Hz. Der WebSocket sendet diese ohne zusätzlichen 16-ms-Ticker sofort weiter und leert bei Rückstau bis zum neuesten Zustand. - **Peak-Schutz:** Sample- und True-Peak-Maxima werden über alle Capture-Blöcke bis zum nächsten Snapshot gesammelt. Muss der WebSocket mehrere Snapshots zusammenfassen, bleiben deren höchste True-Peak-Werte ebenfalls erhalten. - **Abnahme:** Automatische Tests prüfen die periodengrößenunabhängige 60-Hz-Taktung, Peak-Erhalt und Latest-State-Semantik. - [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. Das Spektrogramm besitzt zusätzlich zum eigenen Binär-WebSocket nun auch einen vollständig getrennten Backend-Kanal und behält dadurch seinen FFT-Takt unabhängig von den Mess-Snapshots. Goniometer/Waveform verwenden einen kompakten Binär-WebSocket. Roh-Waveformsamples werden nicht mehr in jedem Capture-Frame vervielfacht; Waveform-Hüllkurven werden bereits zwischen zwei 60-Hz-Snapshots lückenlos gesammelt. 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-Detektor und Reaktionszeiten vollständig und energetisch korrekt implementieren** - **Soll:** Getrennte Auswahl von Average-/Peak-Detektor und der RMS-Reaktionszeit entsprechend der RTW-Bedienlogik. - **Ist:** Average (RMS) und Peak (10 ms) sind getrennte Detektoren; Fast arbeitet mit 125 ms, Slow mit 1 s und Impulse asymmetrisch mit 35 ms Anstieg sowie 1,5 s Rücklauf. Der IIR-Average-Detektor integriert samplegenau im Leistungsbereich; Peak ermittelt gleitend den höchsten gefilterten Samplewert der letzten 10 ms. Beide sind damit unabhängig von der ALSA-Periodengröße. Alte gespeicherte `Average`-/`Peak`-Modi werden automatisch migriert. - **Geprüft:** Regressionstests prüfen Blockgrößenunabhängigkeit, 10-ms-Peakintegration, Impulse-Anstieg/-Rücklauf sowie die Konfigurationsmigration. - **Noch offen:** Medium bleibt mit 0,5 s eine Phoenix-/Legacy-Zeitkonstante, solange kein verbindlicher RTW-Wert vorliegt. Die endgültige dynamische Gerätevalidierung bleibt deshalb 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:** 2,5 s, 4 s und manueller Hold werden samplezeitbasiert im Backend geführt. Der Modus `Hold` springt nach Ablauf eindeutig auf den aktuellen Detektorwert. Der zusätzliche Standardmodus `Hold + Fall` hält zunächst genauso lange und läuft danach mit einstellbaren 1 bis 60 dB/s zurück; Standard sind 20 dB/s. Der Reset erreicht über ein Token sowohl Backend als auch Anzeige. FFT und IIR verwenden dieselbe Hold-Semantik, ohne eine zweite Browser-Holdstufe. - **Noch offen:** Der achtbandige RTW-Speicher ist noch nicht ergänzt. - **Aufgabe:** Acht auswählbare Speicherbänder implementieren und Aktuell-, Hold- und Speicherwert 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. - [x] **10. True Peak kontinuierlich und blockübergreifend korrigieren** - **Soll:** Intersample-Peaks werden unabhängig von ihrer Lage zum ALSA-Block zuverlässig erkannt. - **Ist:** Die vierphasige FIR-Interpolation verwendet die zwölf Referenzkoeffizienten aus ITU-R BS.1770 Annex 2 und besitzt eine kontinuierliche Samplehistorie. Die zuvor an Capture-Blöcken übersprungenen Intervalle werden lückenlos ausgewertet. Hauptbalken, klassische Zeigeransicht und Verlauf teilen eine gemeinsame dBTP-Skala mit sichtbarer Übersteuerungsreserve bis +6 dBTP. - **Geprüft:** EBU-Tech-3341-Testfälle 15 bis 19 einschließlich des +3-dBTP-Intersample-Signals bestehen innerhalb +0,2/-0,4 dB. Synthetische Intersample-Peaks werden oberhalb des Sample-Peaks erkannt; 64, 127, 128, 192 und 511 Samples große Capture-Blöcke liefern denselben Maximalwert. - **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 alte, nicht normgerechte DIN-Sofortmodus wurde vollständig entfernt; ein eigener DIN-Tonbursttest sichert die feste 10-ms-Integration ab. - **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. - [x] **12. VU und RMS softwareseitig eindeutig und reproduzierbar definieren** - **Soll VU:** RTW-artige Moving-Coil-Ballistik mit richtigem Einschwingen, Rücklauf und Überschwingen. - **Ist VU:** Vollweggleichrichtung mit RMS-Kalibrierung und unterdämpftem Moving-Coil-Modell. Der 1-kHz-Sprung erreicht nach 300 ms etwa 99 % und überschwingt um 1 bis 1,5 %; der Rücklauf und mehrere Capture-Perioden werden automatisch geprüft. - **Soll RMS:** Dokumentiertes gleitendes Messfenster mit eindeutigem dBFS-/Kalibrierbezug. - **Ist RMS:** True RMS wird samplekontinuierlich aus der linearen Signalleistung berechnet. Fast (125 ms) und Slow (1 s) verwenden exponentielle Leistungsintegration; alternativ steht ein festes gleitendes 300-ms-Fenster bereit. Die frühere Browser-Nachglättung bereits logarithmierter dB-Werte und der fälschlich als RMS angebotene Impulse-Modus sind entfernt. Hauptbalken, Verlauf und klassische Ansicht verwenden denselben Backend-Messwert und dieselbe dBFS-/dBu-Umrechnung. - **Geprüft:** Stationärer 1-kHz-Sinus ergibt in allen drei Integrationen -3,01 dBFS; 64, 127, 128, 192, 511 und 512 Samples große Capture-Blöcke liefern identische Werte. Fast und Slow werden zusätzlich an ihrer analytischen Sprungantwort geprüft. - **Noch extern zu prüfen:** Pegelkalibrierung und die optische Übereinstimmung mit dem konkreten RTW-PortaMonitor am analogen Eingang. - **Abnahme:** Softwaretests bestehen; endgültige Geräteübereinstimmung folgt mit der analogen Referenzmessung. - [x] **12a. RTA-Oktavauflösung zwischen Einzel- und Mehrfachansichten synchronisieren** - **Ist:** Globale Konfiguration und aktiver DSP konnten durch getrennte API-Aufrufe auseinanderlaufen; beobachtet wurden global 1/6 und gleichzeitig aktiv 1/12. Der Server hält beide Werte jetzt invariant zusammen und repariert auch bereits abweichende Laufzeitzustände. Die eingebettete RTA-Ansicht folgt während des Aktualisierungs-Roundtrips unmittelbar der gewählten Auflösung und kann ein vorhandenes 1/12-Paket verlustfrei auf 1/6 oder 1/3 herunterselektieren. - **Geprüft:** Regressionstests sichern die Backend-Reparatur sowie die lokale 1/12-zu-1/6-Auswahl einschließlich Average- und Peak-Bändern ab. - [x] **13. FFT-Modus als optionale Spektrumsansicht fachlich korrigieren** - **Soll:** FFT ist eine korrekte Zusatzansicht, aber nicht die RTW-IIR-Referenz. - **Ist:** Das FFT-RTA summiert einseitige Binenergien mit Hann-Fensterleistungskompensation. Rand-Bins werden entsprechend ihrem tatsächlichen Bandüberlappungsanteil berücksichtigt; es findet keine Normierung auf die Anzahl oder Gesamtgewichtung der Bins mehr statt. Die native FFT-Integration wird im Browser nicht erneut ausgeführt. Der getrennte Spektrogramm-Amplitudenmaßstab bleibt unverändert. - **Geprüft:** Sinusenergie bleibt bei 2048, 4096, 8192 und 16384 Punkten innerhalb der Testtoleranz konstant. Ein zusätzlicher Test prüft die geometrische Bandenergie bei allen FFT-Größen. - **Abnahme:** Konsistente Pegel bei FFT-Größenwechseln und eindeutig getrennte Kennzeichnung im UI. ## Priorität 3 - Stereoanzeigen und visuelles RTW-Verhalten - [x] **13a. Phasenrad samplekontinuierlich und bildratenunabhängig berechnen** - **Ist:** Bandpass, 33-Tap-Hilbert-Transformation und energiegewichtete komplexe L/R-Kreuzleistung laufen mit der nativen Samplerate kontinuierlich im Audiokern. Der Hilbert-FIR verwendet einen dauerhaften Ringpuffer und bleibt deshalb über ALSA-, Transport- und Browsergrenzen lückenlos. - **Datenweg:** Der Browser erhält mit jedem 60-Hz-Messzustand nur Winkel, Kohärenz, Bandpegel und Bandpeak. Die Phasenrechnung hängt nicht mehr von den für das Goniometer gewählten 128 bis 2048 XY-Punkten ab und belastet den Browser nicht mehr mit Bandpass/Hilbert-DSP. - **Darstellung:** Winkel- und Radiusglättung verwenden reale Zeitkonstanten statt Faktoren pro Grafikframe. Die AGC wird nur mit einem neuen Messzustand fortgeschrieben und richtet den Bandpeak ohne den früheren zusätzlichen Verstärkungsfaktor auf -15 dB aus. - **Geprüft:** Automatische Tests prüfen Phasenwinkel und Kohärenz eines Sinustons, einseitige Signale, erhaltene Filter-/Hilbert-Historie über Snapshots sowie identische Glättung bei unterschiedlicher Bildrate. - [ ] **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, manueller Gain, AGC, Linien/Punkte sowie reproduzierbare Fast-/Medium-/Slow- und freie Phoenix-Persistenz sind vorhanden. - **Datenweg erledigt:** Es werden nur die seit der letzten Ausgabe neu eingegangenen Samplepaare mit im Mittel exakt 60 Hz über den eigenen Binärstrom übertragen. Die Punktzahl begrenzt bereits den Transport; der Browser erfindet keine interpolierten XY-Samples. JSON-Kopien und unbeschränkte Warteschlangen entfallen. - **Darstellung erledigt:** Die Nachleuchtspuren sind auf 48 Zustände begrenzt und verwenden freigegebene `Float32Array`-Puffer erneut. Kosmetische Bézier-Verformung der Messspur ist im RTW-Profil deaktiviert. AGC wird nur bei einem neuen XY-Paket weitergerechnet; das Silence-Gate verwendet das periodengrößenunabhängige XY-Fenster. - **Geprüft:** Automatische Tests prüfen 60-Hz-Taktung bei 44,1/48/96 kHz und unterschiedlichen Periodengrößen, Punktbegrenzung, Endpunkte, Persistenzprofile und Pufferbegrenzung. - **Noch offen:** Die gewählten 50/150/300 ms müssen visuell am echten RTW-Gerät abgeglichen werden; deshalb bleibt der Gesamtpunkt offen. - **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 0,5 s, 1,0 s und 2,5 s sowie Negative-Peak-Memory. - **Ist:** Die Korrelation wird samplekontinuierlich im Audiokern aus gleich integrierten L²-, R²- und L·R-Leistungen berechnet. 0,5 s, 1,0 s und 2,5 s sind wählbar; ein konfigurierbarer Mono-RMS-Silence-Threshold setzt die Anzeige bei Grundrauschen auf Neutralstellung. Der Browser zeigt den fertigen Wert ohne zweite bildratenabhängige Glättung. Negative-Peak-Memory, Marker und manueller Reset sind implementiert. - **Geprüft:** Automatische Tests prüfen +1, 0 und -1, Stille, einseitiges Signal, beide Ansprechzeiten und den Memory-Reset. - **Noch offen:** Dynamische Phasenlagen und das exakte Zeit-/Memory-Verhalten müssen am PortaMonitor verglichen werden; deshalb bleibt der Gesamtpunkt offen. - **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. - **Ergänzt:** RTA und Korrelation besitzen DSP-Tests; die Korrelation prüft jetzt auch einen dynamischen Phasensprung und unterscheidet dabei 1,0 von 2,5 Sekunden. Der Goniometerweg prüft mehrere Sampleraten, Periodengrößen, Punktreduktion und Persistenzprofile. True Peak verwendet den ITU-R-BS.1770-Referenzfilter und prüft EBU-Tech-3341-Fälle 15 bis 19, Intersample-Erkennung und Blockgrenzen; RMS prüft Fast/Slow-Zeitantwort, das exakte 300-ms-Fenster, Pegel und Blockunabhängigkeit. Der Laufzeittest begrenzt zusätzlich das Alter empfangener Messframes auf 500 ms und erkennt damit Transport-Backlogs. - **Noch offen:** Die transienten EBU-Dateitestfälle 20 bis 23, echte Capture-bis-Paint-Latenz und dynamische RTW-Gerätevergleichsreihen. 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.