NeXTsound

Firmware und Mac-App für die NeXT Sound Box mini
26. Oktober 2026
PAP-029

NeXTsound verbindet eine auf einen Mono-Lautsprecher abgestimmte Firmware mit einer nativen Mac-App. Dieses Paper dokumentiert die festgelegten Anforderungen, die Architektur und den erreichten Entwicklungsstand. Die App soll aus allen verfügbaren verwertbaren Chassis-, Gehäuse- und Verstärkerdaten ein DSP-Grundprofil berechnen und optimieren. Die Feinabstimmung erfolgt nach Gehör. Es gibt ein festes Sound-Box-Gehäuse. Profile enthalten neben den Klangeinstellungen die verwendeten Daten und ihre Herkunft.

1. Entwicklungsstand

Die gemeinsame Softwarebasis, der portable DSP-Kern und die USB-/I²S-Integration sind implementiert. Das Paket enthält einen C-Codec für Konfigurationsnachrichten, Swift-Modelle für Klangprofile und die Mono-Signalverarbeitung. Die EQ-Vorschau verwendet dieselben Filterkoeffizienten wie der DSP-Kern. Anforderungen und Architektur stehen im Produkt-Issue.¹ Die Gerätefirmware verbindet USB-Audio, HID-Steuerung und die digitale Ausgabe zum Verstärker.¹³

Die native Mac-App für macOS ab Version 26 öffnet sich auf dem Front Panel, einem Hauptfenster in der Gestalt eines Audiogeräts. Eine Taste auf dem Front Panel öffnet darauf das Library-Panel als Sheet, mit der intern verwalteten Profilbibliothek, dem Lautsprecher des gewählten Profils und dem Namen der SoundBox nebeneinander.³⁴ Die App bearbeitet Klangprofile mit Hochpass, fünf EQ-Bändern, Pegelabsenkung, Limiter und Stummschaltung. Profildateien bleiben Import- und Exportartefakte und bestimmen nicht den Anwendungszyklus.²⁶ Das Display des Front Panels zeigt die lineare Filterwirkung aus denselben Koeffizienten wie die Firmware.

Die App erkennt passende SoundBoxes passiv über USB-HID und verifiziert sie über eine Capabilities-Abfrage. Diese läuft als roher USB-Class-Control-Transfer über libusb, weil IOHIDDeviceGetReport auf diesem zusammengesetzten Gerät die Antwort abschneidet und Apples IOUSBHost-Framework exklusiven Zugriff verlangt, der mit CoreAudio und dem System-HID-Treiber kollidiert.³¹ Jede Änderung geht 250 ms nach der letzten Eingabe an ein verifiziertes Board, ohne in seinen Flash zu schreiben. Auf dem Exemplar ist das am 20. Oktober 2026 bestätigt, und die Ausgabe war hörbar.³⁵ Auf Anforderung speichert die App das aktuelle Profil auf dem Board, setzt seinen Namen und schreibt die mitgelieferte Firmware auf das Board. Einen Reset sendet sie nie. Das Setzen des Namens ist auf dem Exemplar geprüft,³² das Speichern und das Flashen bisher nur gegen Testattrappen.³⁶ Die App wurde in Debug und Release gebaut; die Abbildung unten ist ein Offscreen-Rendering ihrer tatsächlichen SwiftUI-Ansichten.

Die Softwareprüfungen vom 18. Oktober 2026 wurden auf einem arm64-Mac mit macOS 27.2 und Xcode 27.0 ausgeführt. Sie prüfen Nachrichtenformate, Datenmodelle, Signalverarbeitung und USB-Callbacks auf dem Mac. Die Firmware lässt sich für den RP2350 übersetzen. Die Ergebnisse belegen keine physische Audioausgabe.¹⁰

Die aktuelle Geräteprüfung vom 24. Oktober 2026 verwendet Chip XXXXXXXXXXXXXXXX mit dem sauberen Firmwarestand 953d75d4. Ein HID-Prüfer auf dem Mac erfasst Gerätezustand und Live-Zähler, während sox in beiden Audioformaten abspielt. picotool 2.3.1 installiert das Image mit Rücklesevergleich. Die Testprofile bleiben digital stumm.³⁹

Tabelle 1 Erreichte Ergebnisse und ihr Geltungsbereich
Bereich	Stand
Produkt	Die App verwendet ein festes Gehäuse. Vorgesehen sind Chassisauswahl, Offline-Katalog mit passenden Breitbändern verschiedener Hersteller, Online-Datenabfrage und ein modellbasiert optimiertes DSP-Grundprofil.
Architektur	Die Mono-Signalverarbeitung, die gemeinsame USB-Schnittstelle und die Trennung zwischen Änderungen zum Anhören und dauerhaftem Speichern sind festgelegt.
Oberfläche	Das Front Panel und das Library-Panel sind implementiert und als Offscreen-Rendering geprüft. Jeder unbeleuchtete Punkt ihrer Anzeigen ist ein Block aus 3 × 3 Gerätepixeln. Das Ziehen des Fensters am Metall hat der Besitzer am 24. Oktober 2026 in der laufenden App bestätigt (Issue 158). Native Dialoge, Menüaktionen, VoiceOver und das Sheet der Library wurden nicht interaktiv geprüft.
Software	Profilformat, Filtervorschau, DSP, Gerätesteuerung, Audiopuffer und die geometriegeprüfte Anbindung gespeicherter Zustände sind implementiert. Die lokalen Softwareprüfungen sind erfolgreich. Version und Buildnummer der App leitet ein Skript aus der git-Historie ab, und jede Version ist ein Tag mit einem Release auf GitHub, das die gepackte App enthält. Das letzte Release ist app-v0.2.0. Installiert ist die App 0.3.0 mit Build 283, deren Master Volume bis +12 dB reicht. Über 0 dB hebt sie leise Musik an, und der Limiter hält jede Spitze an seiner Obergrenze. Eine App ohne diesen Bereich erkennt eine Box mit Firmware 0.4.0 nicht an.
RP2350-Build	USB-Audio, HID-Steuerung, I²S, dauerhaftes Speichern und der sichere Neustartpfad sind in einem erfolgreichen Firmware-Build enthalten. Hosttests prüfen die Deskriptoren, die Callbacks und ein Modell des erzeugten PIO-Programms. Die Firmware meldet eine Versionsnummer aus einer einzigen Quelle im Build, und das Gate verlangt bei jeder Firmwareänderung eine höhere.⁴⁰ Installiert ist Version 0.4.0 aus dem Quellstand `4bcc975b`, die Master Volume bis +12 dB annimmt und diesen Bereich an die App meldet. Sie speichert zusätzlich Datum, Seriennummer, Besitzer und eine Notiz und nimmt NXSB0000 als Nummer an. Bei den Updates bis 0.3.0 hat sie den bisherigen Speicherstand jedes Mal unverändert übernommen.⁴¹ Native PCM16-/PCM24-Läufe, HID und Gerätespeicher sind auf dem Exemplar geprüft. Maximale Filtereinstellungen und Speichern während PCM24 sind digital stumm geprüft. Jeder Start überschreitet vor dem ersten Stream einmal die Blockfrist, und die Ursache ist offen. Suspend/Resume, Laufzeit-Stack-Höchststände und elektrische Signale sind noch offen.
Flash-Sicherung	Das angeschlossene RP2350-Exemplar ist über seine Chip-ID identifiziert. Sein vollständiger Flash mit 4 MiB ist dreifach übereinstimmend gesichert. Ein Wiederherstellungsweg ist dokumentiert.

Am 18. Oktober 2026 wurde das angeschlossene Exemplar als RP2350 im QFN60-Gehäuse mit Chip-ID XXXXXXXXXXXXXXXX ausgelesen. Seine ursprüngliche Firmware ist MicroPython 1.29.0. Ein gesondertes Diagnoseprogramm lief ausschließlich im SRAM. Untersucht wurden die Identität und die Flash-Metadaten mit picotool 2.3.1 sowie drei vollständigen Flash-Lesevorgängen. Die Audiofirmware wurde bei dieser Metadatenuntersuchung nicht installiert.¹⁴

Die Speicher- und Recovery-Prüfung in Anhang E verwendet den Firmwarestand 7a033203. Die Erstinstallation startete digital stumm. Einstellungen wurden gespeichert, nach Neustart wieder eingelesen und nach einer gezielten Beschädigung des neuesten Testdatensatzes aus dem älteren Stand wiederhergestellt. Alle Testprofile blieben digital stumm. Eine USB-Audioübertragung wurde dabei nicht gestartet.¹⁹

Der erste PCM24-Start ist fehlgeschlagen; danach antwortete HID nicht mehr. Dieser Ausgangsbefund ist gesichert.²⁰ Mit einem RP2-Treiber, der laufende Transfers vor der Reaktivierung eines ISO-Endpunkts beendet, bestehen die nativen Formatwechsel PCM16, PCM24 und zurück zu PCM16 sowie parallele HID-Abfragen. Auch die Rückkehr zu BOOTSEL per USB funktioniert.²¹ Ein weiterer PCM24-Lauf prüft alle sechs Filter mit Parametergrenzen sowie zwei Speichervorgänge während der Audioübertragung. Der vorherige stumme Zustand ist danach wieder gespeichert. Ein tatsächlicher USB-Suspend ist noch nicht bestätigt.²²

Die Live-Diagnose trennt die Ursachen der Laufzeitzähler. Der Unterlauf beim Stoppen stammt aus dem Eingangspuffer.²⁴ Während der geprüften Streams ändern sich I²S-Stalls, DSP-Fehler und Fristüberschreitungen nicht. Zehn fehlerhafte HID-Anfragen verändern weder Profil noch Zustandsgeneration. Nach den Läufen ist der Zustand von vor der Installation bytegleich als Generation 99 gespeichert. Jeder Start meldet vor dem ersten Stream einen Verarbeitungswert über der Blockfrist von 1000 Mikrosekunden und zwei I²S-Stalls. Woher sie kommen, ist offen.³⁹ Suspend/Resume bleibt offen, weil bisher kein tatsächlicher Zyklus bestätigt ist.

Für das Projekt ist das Lautsprecherchassis Tectonic Elements TEBM28C10-4 angegeben. Das vollständig gelesene Herstellerdatenblatt bezeichnet TEBM28C10-4/A und nennt 4 Ω Nennimpedanz. Die Leistungsangabe von 10 W setzt gewichtetes rosa Rauschen und einen Hochpass zweiter Ordnung voraus; dessen Grenzfrequenz ist nicht angegeben. Ein physischer Abgleich der Modellrevision steht aus.²⁷ Das Nettoluftvolumen des endgültigen, laut Besitzer akustisch dichten Gehäuses ergibt sich aus einem eigens modellierten Innenraum abzüglich Chassis und Platine.³⁸ Die Einbaugrenzen stammen aus dem zusammengesetzten STEP-Modell NeXT SoundBox Complete.step eines früheren Konstruktionsstands, siehe Anhang M.

Nettoluftvolumen des Gehäuses

Der modellierte Innenraum umfasst abzüglich Chassis und Platine rund 0,178L Abgeleitet. Die Volumina stammen aus den Dreiecksnetzen der einzeln exportierten Teile und sind mit keinem zweiten Geometriekern gegengeprüft. Verstrebungen, Kleber, Dämpfung und Leitungen sind nicht enthalten. Der Wert ist kein Nachweis der physischen Dichtigkeit des gedruckten Gehäuses.³⁸

Vorgesehen sind das Waveshare RP2350-Zero-M und das fotografierte MAX98357A-Breakout. Die Verdrahtung und die Bedeutung der Anschlüsse stehen im Verdrahtungs-Paper PAP-027. Die Softwarekennung belegt nicht das physische Platinenmodell. Verdrahtung, Last und elektrische Audiosignale sind weiterhin zu prüfen.

2. Klangprofile und Bedienung

Der Ablauf beginnt mit der Eingabe oder Auswahl des Chassis. Ein mitgelieferter Offline-Katalog enthält mechanisch passende Breitbänder verschiedener Hersteller. Die Passform berücksichtigt Öffnung, Befestigung, Rahmen, Tiefe, Anschlüsse und Freiraum im festen Gehäuse. Online verfügbare Parameter werden mit Quellen und Datenstand ergänzt und lokal zwischengespeichert. Das Gehäuse ist einmal ausgewertet und als feste Produktgrundlage hinterlegt.

Die App soll daraus ein modellbasiertes DSP-Profil berechnen und optimieren. Alle vorhandenen verwertbaren Parameter und Herstellerkurven sollen in die Rechnung eingehen. Hinzu kommen die bestätigte Gehäusegeometrie, Verstärker, Versorgung und verfügbare DSP-Funktionen. Das Ziel ist ein ausgewogener modellierter Frequenzgang mit sinnvoll nutzbarem Pegel innerhalb bekannter Grenzen. Hochpass, fünf EQ-Bänder, Pegelreserve und Limiter werden gemeinsam bestimmt. Fehlende Daten, Modellannahmen und nicht nutzbare Eingaben bleiben nachvollziehbar. Ein allgemeines Preset ist kein Ersatz für diese Berechnung.²⁸

Nach der Berechnung lassen sich Hochpass, Equalizer, Lautstärke und Limiter beim Anhören verändern. Ein A/B-Vergleich wechselt zwischen zwei Bearbeitungsständen für dasselbe Chassis und feste Gehäuse. Ein benanntes Klangprofil hält das Ergebnis fest. Implementiert sind die Bearbeitung der DSP-Einstellungen und ihre Übernahme auf das Board beim Anhören. Sind Fs, Qts und Vas des gewählten Lautsprechers bekannt, setzt seine Wahl bereits den Hochpass und das erste EQ-Band aus der Closed-Box-Abstimmung mit dem festen Gehäuse.³⁷ Die A/B-Speicher bestehen bisher nur im Datenmodell, ohne Bedienelemente. Datenabfrage und vollständige Profilberechnung gehören zum geplanten Lieferumfang.

Ein Equalizer, kurz EQ, hebt ausgewählte Frequenzbereiche an oder senkt sie ab. Seine Vorschau zeigt die eingestellte Filterwirkung. Sie ist keine gemessene Frequenzkurve des Lautsprechers. Ein Hochpass senkt tiefe Frequenzen ab. Der Limiter begrenzt digitale Signalspitzen. Seine Einstellung allein belegt weder einen Schutz vor Überhitzung noch vor zu großer Membranauslenkung.

Tabelle 2 Festgelegter Inhalt eines Klangprofils
Inhalt	Bedeutung
Profil	Name, eindeutige Kennung und Fassung. Berechnete Profile sollen zusätzlich die verwendeten Eingaben, die Berechnungsfassung und Modellannahmen enthalten. Manuell gewählte Presets behalten ihre Herkunft.
Klangeinstellungen	Hochpass, fünf parametrische EQ-Bänder, Pegelabsenkung, Limiter und digitale Stummschaltung.
Lautsprecher	Eine gespeicherte Kopie des ausgewählten Lautsprechertyps mit seinen belegten Daten und Quellen. Eine spätere Änderung im Katalog verändert bestehende Profile nicht unbemerkt.
Gehäuse	Feste Sound-Box-Daten mit nutzbarem Luftvolumen, akustischer Bauform, Modellbezug und Berechnungsgrundlage. Bekannte Verdrängung und Einbaugrenzen werden berücksichtigt.

Das feste 3D-Modell liefert nach seiner Prüfung die geometrischen Eingaben. Sein Volumen allein bestimmt keine EQ-Kurve. Die Berechnung verbindet Gehäuse und Chassis mit den weiteren verfügbaren Systemdaten. Ihre Vorhersage bleibt von akustischen Messwerten unterscheidbar. Eine Mikrofonmessung ist keine Voraussetzung für die Profilberechnung oder Feinabstimmung. Aussagen zu thermischen und mechanischen Grenzen reichen jeweils nur so weit wie die belegten Eingaben und das anwendbare Modell.

Das implementierte Profilformat prüft seine Fassung und die enthaltenen Werte beim Einlesen und beim Schreiben. Ungültige Frequenzen, nicht endliche Zahlen und widersprüchliche Volumenangaben werden abgewiesen. Fehlende Lautsprecherdaten und ein unbekanntes Gehäusevolumen bleiben ausdrücklich unbekannt.

Für die Bedienung sind das Speichern eines Profils auf dem Mac und das dauerhafte Speichern des aktiven Klangs auf dem Board als getrennte Aktionen festgelegt. Reglerbewegungen und A/B-Vergleiche betreffen den laufenden Zustand. Für das dauerhafte Speichern ist ein eigener Nachrichtentyp festgelegt.

3. Firmware und Verbindung zum Mac

Der implementierte DSP-Kern verarbeitet Stereo-Samples. Aus linkem und rechtem Kanal entsteht ihr Mittelwert. Darauf folgen ein Hochpass zweiter Ordnung, fünf EQ-Bänder, Pegelabsenkung, Limiter und digitale Stummschaltung. Vollständige neue Einstellungen werden über fünf Millisekunden eingeblendet. Die Filtervorschau berechnet nur die lineare Wirkung von Hochpass und EQ.

Die Firmware nimmt Stereo-Audio vom Mac entgegen und schreibt das Mono-Ergebnis in beide Kanäle ihrer I²S-Ausgabe. I²S ist die digitale Audioverbindung zum Verstärker. Der implementierte Ausgabepfad verwendet GP6 als Datenleitung, GP14 als Bittakt und GP15 als Worttakt. Seine tatsächlichen elektrischen Signale sind noch zu messen.

DSPi 1.1.5 ist die Referenz für die reduzierte Signalverarbeitung. Sein Quelltext enthält die Verarbeitung von Hochpass- und parametrischen Filtern.² Übernommener Code bleibt unter den Lizenzbedingungen des Originals. Das DSPi-Repository enthält die GNU General Public License in Version 3.³

Betrieb innerhalb der Herstellerspezifikation

Raspberry Pi spezifiziert den RP2350 mit 150 MHz.⁴ Diese Taktrate ist für NeXTsound festgelegt. Die untersuchte DSPi-Version fordert beim Start 307,2 MHz an.⁵ Daraus folgt keine nachgewiesene Instabilität. Die ausreichende Rechenreserve der reduzierten Firmware bei 150 MHz ist durch ihre Laufzeitprüfung zu belegen.

Audio und Konfiguration sind getrennte USB-Funktionen. Der Audiokanal verarbeitet 48 kHz mit 16 Bit oder gepackten 24 Bit. Eine eigene HID-Schnittstelle überträgt die Einstellungen. HID steht für Human Interface Device und bezeichnet hier die USB-Geräteklasse des Konfigurationskanals. Die Integration verwendet das festgelegte TinyUSB 0.21.0 und passt dessen Lautsprecherbeispiel an.⁶ Die Kombination ist mit nativen PCM16-/PCM24-Läufen und parallelen HID-Abfragen auf dem genannten Exemplar geprüft.

Konfigurationsnachrichten enthalten eine Protokollfassung und die Kennung ihrer Anfrage. Die Firmware bestätigt neue Klangeinstellungen erst nach der Übernahme durch den Audio-Kern. Dabei steigt die Zustandsgeneration. Beim erneuten Verbinden soll die App zunächst die Fähigkeiten und Einstellungen des Boards lesen. Ein älteres lokales Profil darf den Board-Zustand nicht automatisch überschreiben.

Der Audiokern verarbeitet vollständige Blöcke und bereitet den nächsten Ausgabepuffer vor, während der vorherige übertragen wird. Eine Einblendung begrenzt die Pegelsprünge beim Starten, Stoppen und erneuten Einpuffern. Beim USB-Ruhezustand endet die Ausgabe mit einem stummen Block. Diese Abläufe sind auf dem Host geprüft; Störgeräusche und Stromaufnahme sind damit nicht gemessen.

Der portable Speicherkern verwendet zwei prüfbare Datensätze. Sein Host-Modell erhält den vorherigen gültigen Stand bei unterbrochenen Schreibvorgängen. Er liest beide Datensätze vor jedem Speichern erneut und bestätigt einen neuen Stand erst nach vollständigem Rücklesevergleich. Die Anbindung an Gerätesteuerung und Flash-Zugriff ist im Hosttest und Firmware-Build enthalten.¹⁸ Speicherzugriffe setzen die bestätigte Flash-Geometrie und eine angehaltene Audioausgabe voraus. Speichern und Wiederanlauf sind auf dem Exemplar geprüft. Die stummen PCM24-Speicherläufe sind in Anhang H und I dokumentiert. Das Exemplar ist identifiziert und sein vollständiger Flash gesichert.

4. Die Oberfläche

Die gestalterische Richtung ist ein Audiogerät auf dem Mac. Das Front Panel besteht aus fein gekörntem Metall mit einem Multifunktionsdisplay aus Leuchtpunkten und einer Reihe aus Schiebereglern, Tastenbänken, Schiebeschaltern und LEDs. Fensterverhalten, Menüs und Tastaturbedienung bleiben native macOS-Funktionen. Die App ist mit Swift und SwiftUI implementiert.³⁴

Das Display zeigt links die Kurve des gewählten Profils und darunter seinen Namen. Rechts stehen der Verbindungsstatus der SoundBox und für ein verifiziertes Board Name, Seriennummer, Firmware, Audioformat, Flash mit Speicherstand, Live-Werte und die gesetzten Besitzerangaben. Meldungen erscheinen in einer Card mit abgerundeten Ecken in der Mitte des Displays, mit einem gedimmten Rahmen und höchstens vier Zeilen. Solange die Card steht, leuchtet der übrige Inhalt des Displays gedimmt. Ein Fehler erscheint sofort und bleibt, solange er besteht. Jede andere Meldung erscheint, wenn sie eine halbe Sekunde besteht, und verschwindet nach vier Sekunden. Ein Speichern auf die SoundBox bleibt stehen, solange es läuft.⁴² Die Reihe unter dem Display bearbeitet das gewählte Profil. Das Bandpanel stellt mit drei Schiebereglern das Band ein, das seine fünf Tasten wählen. Die Module für Hochpass, Ausgang und Limiter halten die übrigen Regler, die Schalter für Hochpass und Stummschaltung sowie die Tasten SAVE und FLASH. Die Skala neben jedem Regler hat ihre Striche auf runden Werten, etwa bei 100 Hz, 1 kHz und 10 kHz, und auf Master Volume und dem Band-Gain ist der Strich bei 0 dB länger. Rechts wählen drei Tasten die Farbe der Anzeigen. Unter BLUE schaltet die Taste SPECTRUM das Display von der Kurve auf einen Live Spectrum Analyzer und wieder zurück. Er zeigt, was die SoundBox an ihren Verstärker gibt: Die App nimmt den Ton ab, den macOS an die Box schickt, und rechnet ihn mit der Host-Lautstärke und derselben DSP wie die Firmware durch, mit den Einstellungen des gewählten Profils. Seine Balken stehen in Sechsteloktaven über derselben Frequenzskala, auf einer Pegelskala von 0 bis -60 dB unter Vollaussteuerung. Wird die Box neu angeschlossen, startet das Spektrum von selbst wieder, sobald macOS die Aufnahme zulässt. Unter AMBER schiebt die Taste INFO die Statusspalte aus dem Display und wieder herein, und solange sie draußen ist, nimmt die Kurve oder das Spektrum die ganze Breite ein. Ganz unten öffnet die Taste LIBRARY das Library-Panel. Tasten, die eine Auswahl treffen, sind grau. Tasten, die etwas auslösen oder einrasten, haben das Gelb der Streifen in der Kopfzeile, auch im Library-Panel, und der runde Button FLASH hat ihr Rot.

Das Library-Panel listet die Profile mit den Tasten NEW, DELETE, IMPORT und EXPORT. Ein Doppelklick benennt ein Profil direkt in der Liste um. Daneben stehen der Lautsprecher mit dem Menü aller Treibermodelle und der Name der SoundBox mit der Taste RENAME, und die Taste CLOSE schließt das Sheet. Die Profilbefehle stehen auch im Menü Ablage. Erklärende Texte in Dialogen behalten die normale Textgröße und werden über ihre Farbe zurückgenommen. Apples Richtlinien nennen für macOS 13 pt als normale Textgröße.⁷

Das App-Icon zeigt ein in Blender gerendertes Lautsprecherchassis vor der Punktmatrix des Displays mit der phosphorblauen EQ-Kurve. Unten laufen die vier Streifen, und das Chassis ragt in den roten hinein und wirft seinen Schatten auf sie.³⁴ Eine Profildatei mit der Endung .nxsbprofile zeigt im Finder dasselbe Bild, nur steht an der Stelle des Chassis ein Blatt Papier mit Eselsohr. Darauf steht in Inter Tight kursiv Steve Jobs’ Zitat „Sometimes life hits you in the head with a brick …“, um das Eselsohr herum gesetzt, darunter fett sein Name. Unten ist mittig die Zeile „-- printed on a NeXT Laser Printer, 400 dpi --“ gedruckt.

Library-Panel als Sheet mit drei Spalten nebeneinander: die Profilliste mit den gelben Tasten NEW, DELETE, IMPORT und EXPORT, der Lautsprecher Dayton Audio CE41N-4 über der gelben Taste DRIVER MODELS, der Name Bedroom SoundBox mit der leuchtenden LED CONNECTED rechts neben dem Titel, der gelben Taste RENAME und der gelben Taste CLOSE. — Abbildung 1 Offscreen-Renderings der implementierten SwiftUI-Ansichten bei Skalierung 2, mit Beispielprofilen und einem simulierten verifizierten Board. Es sind keine Screenshots einer laufenden App. Links steht das Library-Panel, das als Sheet auf dem Front Panel erscheint, rechts das Front Panel: 1 Kopfzeile mit Wortmarke, 2 Kurve des gewählten Profils, 3 Statusspalte, 4 Bandpanel mit den fünf Bandtasten, 5 Hochpass, 6 Ausgang, 7 Limiter mit SAVE und FLASH, 8 Farbe der Anzeigen mit den Tasten INFO und LIBRARY, 9 Profile mit ihren Tasten, 10 Lautsprecher mit der Taste DRIVER MODELS, 11 SoundBox mit der LED CONNECTED am Titel, dem Namen, RENAME und CLOSE. Die Werte des Front Panels gehören zum Preset Warm und sind keine Lautsprecherkalibrierung.

Prommer ist die visuelle Referenz für den Retro-Charakter, und die Kopfzeile übernimmt seine vier LAYERED-Streifen.⁸ NeXTsound verwendet eine eigene Farbpalette und eine auf Klangabstimmung ausgelegte Anordnung. Die Systemfenster und das unmittelbare Feedback beim Verstellen eines Schiebereglers entsprechen Apples Vorgaben.⁹

5. Aussagegrenzen

Die Befunde betreffen Quelltext, Hosttests, Firmware-Builds und die Flash-Untersuchung des genannten Exemplars. Das SRAM-Diagnoseprogramm und die installierte Firmware wurden auf dem Exemplar ausgeführt. Die Speicherprüfung betrifft HID-Steuerung und Speicherung ohne USB-Audiostream. Die anschließenden nativen Formatprüfungen verwenden einen Audiostream. Der initiale PCM24-Fehler und die erfolgreiche Wiederholung mit korrigiertem Treiber sind getrennt dokumentiert. Der ursprüngliche vollständige Flash ist gesichert; seine Wiederherstellung ist dokumentiert, aber noch nicht ausgeführt. Die gezielte Record-Beschädigung ist kein physischer Stromausfall. Die instrumentierten stummen Audio-, Filter- und Speichertests gelten für die beschriebenen Läufe. Die Fristüberschreitung beim Start ist beobachtet, aber weder ihrem Programmteil zugeordnet noch auf Hörbarkeit geprüft. Nicht stumme Laufzeit, tatsächlicher USB-Suspend, Laufzeit-Stack-Höchststände, elektrische I²S-Signale und Stromaufnahme bleiben offen. Die verwendeten USB-Kennungen sind ausschließlich Entwicklungskennungen.

Die App-Befunde betreffen Profilbibliothek, lokale Speicherung, Board-Anbindung über injizierte Testattrappen, Datenvalidierung, Builds und Offscreen-Ansichten. Auf dem Exemplar sind der lesende Capabilities-Austausch, das Setzen des Namens und die Übernahme von Änderungen mit hörbarer Ausgabe bestätigt. Das Speichern auf dem Board und das Flashen aus der App sind nur gegen Testattrappen geprüft. Native Datei- und Menüdialoge, VoiceOver und das Sheet der Library wurden nicht interaktiv ausgelöst. Das gelesene Lautsprecherdatenblatt liefert deklarierte Herstellerwerte, aber keine gemessenen Werte des eingebauten Exemplars oder geprüfte Schutzfilter. Das Nettoluftvolumen beruht auf den Netzvolumina von Innenraum, Chassis und Platine, und die Montagebezüge stammen aus dem früheren Konstruktionsstand. Physische Dichtigkeit, vollständige Einbauten und Drucktoleranzen sind damit nicht bestimmt.

Ein erfolgreicher Build belegt keine störungsfreie Audioausgabe und keine Schutzwirkung für einen bestimmten Lautsprecher. Die digitale Stummschaltung schaltet den Verstärker nicht ab. Eine modellierte Systemantwort ist eine Vorhersage unter ihren angegebenen Daten und Annahmen. Sie belegt nicht den am Aufbau gemessenen Frequenzgang.

Quellennachweis

Die für die Software- und Firmwarebefunde verwendeten Quellen wurden am 18. Oktober 2026 eingesehen. Das Lautsprecherdatenblatt in Quelle 27 wurde vollständig gelesen; das STEP-Modell wurde mit den in Quelle 29 beschriebenen Methoden geometrisch ausgewertet. Beim Flash-Datenblatt beziehen sich die Angaben auf die vollständigen Abschnitte zu Page Program und Read Identification. Bei der DSPi-Startfunktion wurde der zugehörige Funktionsbereich untersucht.

NeXTsound: Define the NeXTsound firmware and macOS app baseline. GitHub-Issue mit Anforderungen und Architekturentscheidungen. Issue 1 ↩
WeebLabs: DSPi v1.1.5, dsp_biquad.h. RP2350-Filterverarbeitung. Quelltext ↩
WeebLabs: DSPi v1.1.5, LICENSE. GNU General Public License, Version 3. Lizenztext ↩
Raspberry Pi Ltd: RP2350 Product Brief. Seite 3. Hersteller, lokale Kopie↩
WeebLabs: DSPi v1.1.5, main.c. Initialisierung des Systemtakts. Funktionsbereich ↩
TinyUSB: uac2_speaker_fb, usb_descriptors.c. Festgelegter Quellstand dae3f9a von TinyUSB 0.21.0. Quelltext, lokale Kopie ↩
Apple: Human Interface Guidelines, Typography. Richtlinie ↩
Prommer: README und Produktabbildung. Repository ↩
Apple: Human Interface Guidelines, Windows und Sliders. Fenster und Slider ↩
NeXTsound: Lokale Prüfungen am 18. Oktober 2026. Vollständiger Prüflauf um 08:05 Uhr, aktualisierte Firmware- und C-Prüfungen um 08:19 Uhr, C-Ergebnisse und Kennwerte und Quellenprüfsummen ↩
Raspberry Pi: Pico SDK 2.2.0. Festgelegter Quellstand des RP2350-Builds. SDK-Quellstand ↩
Arm: GNU Toolchain 15.3.Rel2. Paketmetadaten mit SHA-256-Prüfsummen. Compiler-Paket ↩
NeXTsound: USB-Audio-, HID- und I²S-Integration. Implementierung und Prüfgrenzen in Issue 8 und der Firmware-Dokumentation ↩
NeXTsound: Flash-Untersuchung am 18. Oktober 2026. Identität, Metadaten und Sicherungsnachweis ohne Flash-Inhalte. Die vollständigen Images und Wiederherstellungsanweisungen bleiben im privaten Backup-Verzeichnis. Issue 9 ↩
Puya Semiconductor: PY25Q32HB Datasheet V1.7. Abschnitt 10.25 auf Seiten 55 und 56 sowie Abschnitt 10.35 auf Seite 67. Herstellerdatenblatt, lokale Kopie ↩
NeXTsound: Vollständige lokale Prüfungen mit SRAM-Diagnose-Build. Prüflauf um 09:30 Uhr, C-Testergebnisse sowie Abweisung eines Flash-ELFs und Build mit automatischer positiver und negativer SRAM-Prüfung um 09:35 Uhr ↩
NeXTsound: Lokale Softwareprüfungen mit portablem Speicherkern. Vollständiger Prüflauf um 09:53 Uhr und C-Testergebnisse ↩
NeXTsound: Softwareintegration der Persistenz am 18. Oktober 2026. Vollständiger Prüflauf um 10:53 Uhr und C-Testergebnisse ↩
NeXTsound: Speicherprüfung auf dem RP2350-Exemplar am 18. Oktober 2026. Strukturierte Beobachtungen ohne Flash-Inhalte, gezielter HID-Prüfer, kanonische Record-Prüfung und Build des installierten Quellstands ↩
NeXTsound: Begonnene Audioformatprüfung am 18. Oktober 2026. PCM16-Beobachtungen und PCM24-Fehlerzustand und nativer HAL-Prüfer. Initialer Fehlerzustand vor der Treiberkorrektur.↩
NeXTsound: ISO-Neustartkorrektur und native Formatprüfung am 18. Oktober 2026. Kandidat, Formatläufe und Aussagegrenzen, fehlschlagender Originaltreiber, Gesamtcheck um 12:07 Uhr und C-Ergebnisse. Der Prüfkandidat verwendete die Treiberdatei mit der TinyUSB-Korrektur 102c199.↩
NeXTsound: Maximale Filtereinstellungen und Gerätespeichern während PCM24 am 18. Oktober 2026. Einstellungen, Zustände, Generationen und Aussagegrenzen. Der native Audioprüfer verwendet den gezielten HID-Prüfer. Der erste Port-Suspend-Prüfer bestätigt trotz erfolgreichem Aufruf keinen gesetzten Suspend-Status nach einer Sekunde; dieser Teil gilt nicht als bestanden.↩
NeXTsound: Rückkehr über BOOTSEL und Diagnosegrenze am 18. Oktober 2026. SRAM-Versuch, erneute USB-Erkennung und wiederhergestellte Generation 5. Die untersuchten SRAM-Werte stimmen nach BOOTSEL nicht mit der bekannten Laufzeittelemetrie überein und werden nicht als auswertbare Live-Zähler behandelt.↩
NeXTsound: Live-Diagnose am 18. Oktober 2026. Image, Installation, Kompatibilität, Audio-, Speicher- und Fehlerfälle, vollständiger Softwarecheck um 14:01 Uhr, C-Ergebnisse, Zähler-Gegenproben und Speicherformat-Gegenprobe. Der Diagnoseprüfer verwendet die gemeinsamen HID-Hilfsfunktionen; unmittelbares AudioUnit-Schließen bildet den Vergleichsfall. CI des installierten Quellstands ↩
NeXTsound: Gezielte USB-Ruheversuche und Interruptmodell am 18. Oktober 2026. Gerätebeobachtungen mit verändertem eigenen Clientzugriff, geschlossener Gerätezugriff, freigegebener User-Client, Interrupt-Prüfmodell, vollständiger Softwarecheck um 15:18 Uhr, C-Ergebnisse, Suspend-Gegenprobe und Resume-Gegenprobe ↩
NeXTsound: Native Offline-Werkbank am 18. Oktober 2026. Build-, Test- und Renderingnachweise, vollständiger Softwarecheck, C-Ergebnisse, beobachteter Ordner-Importfehler und beobachteter Generatorfehler. Apple beschreibt FileDocument und DocumentGroup. App-Lieferabschnitt ↩
Tectonic Audio Labs und NeXTsound: Lautsprecherdatenblatt und bereitgestellte Geometrie. Lautsprecherbezeichnung und Datenblatt-Link sind in Issue 15 verzeichnet. Das zusammengesetzte STEP-Modell ist in Issue 17 erfasst. Das Hersteller-PDF wurde vollständig gelesen; die Textextraktion ergänzt die Seitenansicht. Die physische Modellrevision bleibt offen. Die STEP-Geometrie ist in Quelle 29 ausgewertet.↩
NeXTsound: Modellbasierte Grundprofile für das feste Sound-Box-Gehäuse. Geplanter Umfang und Kataloggrenzen in Issue 15, Geometrieprüfung in Issue 17, Berechnung in Issue 19 und A/B in Issue 20. Diese Punkte beschreiben Anforderungen, keine bereits implementierte Profilberechnung.↩
NeXTsound: Geometrieprüfung der festen Sound Box am 18. Oktober 2026. Strukturierte Montage- und Volumenbezüge, Inventar, Montageflächen und Überschneidungen, verbundene Lufträume mit Kontrollkörpern und benannte virtuelle Abschlussräume. Die privaten Auswertungsskripte stehen bei den Rohdaten; die Quelldatei bleibt außerhalb Git. OCP-Distribution und Issue 17 ↩
NeXTsound: Hauptfenster-Werkbank mit Profilbibliothek und Board-Erkennung am 19. Oktober 2026. Build-, Test-, Rendering- und Board-Zugriffsnachweise. Die passive Erkennung und der eine lesende Capabilities-Austausch liefen gegen das Exemplar XXXXXXXXXXXXXXXX außerhalb der Produkt-GUI; sein Antwortroundtrip kam nicht vollständig an. Issue 21 und der ungelöste Capabilities-Roundtrip in Issue 22 ↩
NeXTsound: Behebung des Live-Capabilities-Roundtrips am 19. Oktober 2026 (Nachmittag). Gate-, Root-Cause- und Board-Zugriffsnachweise. Geprüft mit der sichtbar gestarteten App gegen das Exemplar XXXXXXXXXXXXXXXX. Issue 22 ↩
NeXTsound: Persistenter SoundBox-Name am 19. Oktober 2026 (Abend). Gate-, Root-Cause- und Board-Zugriffsnachweise. Firmware geflasht und Name gesetzt/gelesen/zurückgesetzt gegen das Exemplar XXXXXXXXXXXXXXXX. Issue 24 ↩
NeXTsound: Behebung des Namens in den Tonausgabe-Einstellungen am 19. Oktober 2026 (Abend). Gate-, Root-Cause- und Board-Zugriffsnachweise. Geprüft über system_profiler SPAudioDataType gegen das Exemplar XXXXXXXXXXXXXXXX. Issue 27 ↩
NeXTsound: Front Panel und Library-Panel am 22. und 23. Oktober 2026. Die Lieferabschnitte Issue 72, 73, 74, 75 und 76 der Epic 77, Issue 98 für die Taste LIBRARY, Issue 100 für die Wortmarke, Issue 111 für das Sheet der Library, Issue 113 für die Lage seiner beiden LEDs, Issue 119 und 121 für die breiteren Tasten, Issue 123 für die Taste INFO, Issue 124 für die gelben Tasten, Issue 127 für den roten Button FLASH, Issue 129 für das App-Icon, Issue 131 und 133 für das gekörnte Metall, das Mockup, die App-Dokumentation, der abschließende Prüflauf sowie die Renderings des Front Panels, des Library-Panels und des App-Icons ↩
NeXTsound: Übernahme von Änderungen auf das Exemplar am 20. Oktober 2026. Issue 43 mit den Messwerten der hörbaren Wiedergabe und der Abschnitt zur Board-Erkennung in der App-Dokumentation ↩
NeXTsound: Speichern auf dem Board und Flashen aus der App. Issue 62 und Issue 41. Beide sind gegen Testattrappen geprüft, nicht auf dem Exemplar.↩
NeXTsound: Closed-Box-Abstimmung bei der Lautsprecherwahl. Die DSP-Dokumentation, die Treibermodelle in Issue 15 und die A/B-Speicher in Issue 20 ↩
NeXTsound: Nettoluftvolumen des endgültigen Gehäuses am 21. Oktober 2026. Strukturierter Datensatz mit Methode und Grenzen und seine lokale Kopie. Er ersetzt die Volumina der Quelle 29. Issue 17 ↩
NeXTsound: Firmwarestand 953d75d4 auf dem Exemplar am 24. Oktober 2026. Strukturierter Datensatz und seine lokale Kopie. Die Rohausgaben zeigen den Stand vor der Installation, die Installation, den Stand danach, die fehlerhaften Anfragen, die Formatläufe mit ihren Zählerabfragen, den Neustart und die Wiederherstellung. Dazu kommen der HID-Prüfer, das Formatwerkzeug und der vollständige Prüflauf. Offen sind der physische Suspend/Resume-Zyklus in Issue 166 und die Fristüberschreitung beim Start in Issue 167.↩
NeXTsound: Versionsnummer der Firmware am 24. Oktober 2026. Festlegung und Gate-Prüfung im Abschnitt Version der Firmware-Dokumentation. Die Capabilities des Exemplars XXXXXXXXXXXXXXXX melden nach der Installation 0.1.0, picotool info zeigt 0.1.0 (7914d0c0). Issue 168 ↩
NeXTsound: Besitzerangaben mit Firmware 0.2.0 am 24. Oktober 2026. Strukturierter Datensatz und seine lokale Kopie. Die Rohausgaben zeigen den Stand vor dem Update, die Installation, den Stand danach, das Schreiben, den Neustart und das Leeren; dazu der HID-Prüfer. Das Update auf 0.3.0 zeigen der Stand davor, die Installation und der Stand danach; Issue 177. Das Speicherformat beschreibt die Speicherdokumentation, die Operationen die Protokolldokumentation. Issue 39 ↩
NeXTsound: Meldungs-Card am 24. Oktober 2026. Issue 175 und Pull Request 179. Die Offscreen-Renderings zeigen eine einzeilige Meldung, eine dreizeilige Fehlermeldung und das Front Panel der Abbildung 1.↩

Anhang

Arbeitsgrundlagen und Regeln für die Fortschreibung. Für die Beschreibung oben ist dieser Teil nicht erforderlich.

A. Arbeitsgrundlagen und Dokumentpflege

Die lokale Arbeitskopie liegt unter ~/Developer/Projects/NeXTsound. Repository und Projektboard sind privat. Die Planung bleibt in den Issues. Dieses Paper beschreibt jeweils den erreichten Zustand und seine Grundlagen. Neue Ergebnisse ersetzen die betreffenden Standangaben. Prüfberichte nennen Gerät, Firmware, Werkzeug und Datum.

Die Dokumentkennung ist PAP-029. Der Ordner Papers steht außerhalb der Versionsverwaltung. Die lokale Papers-Übersicht und die globale Projektübersicht werden zusammen mit dem Dokument gepflegt.

B. Softwareprüfungen und RP2350-Build

Der lokale Prüflauf im Firmware-/Diagnosezweig vom 18. Oktober 2026 endete um 15:18 Uhr erfolgreich.²⁵ Der portable Speicherkern ist außerdem im Prüflauf um 09:53 Uhr dokumentiert.¹⁷ Der vorherige Prüflauf dokumentiert die SRAM-Buildprüfung.¹⁶ Geprüft wurde mit bash Scripts/check.sh, ShellCheck und Actionlint. Die Toolchain ist in toolchain.json festgelegt. Verwendet wurden Xcode 27.0 mit Build 27A266a, SwiftFormat 0.64.0 und SwiftLint 0.65.0. Der C-Teil wurde mit AddressSanitizer und UndefinedBehaviorSanitizer gebaut. Die 20 CTest-Fälle bestehen aus 19 positiven Fällen mit insgesamt 316.522 erfolgreichen Assertions und einer erwarteten Fehlerkontrolle mit dem unveränderten ursprünglichen RP2-Treiber. Alle 31 Swift-Tests, die Formatierungsfixtures, der Linter und die Release-Builds sind erfolgreich. Der vollständige Prüflauf des Firmwarestands 953d75d4 steht in Anhang J.

Der RP2350-Build verwendet Pico SDK 2.2.0¹¹ und Arm GNU Toolchain 15.3.Rel2 mit GCC 15.3.1.¹² Das Build-Werkzeug picotool 2.3.1 wird aus seinem festgelegten Quellstand ohne USB-Zugriff gebaut. Die Prüfung umfasst die USB-/I²S-Firmware, den gesonderten DSP-Probe-Build und das SRAM-Diagnoseprogramm. Board-Definition und Firmwaredatei sind keine Messung der tatsächlichen Flash-Kapazität.

Die USB-Callback-Tests verwenden die tatsächliche Callback-Implementierung mit einer Host-Testumgebung. Drei Fehlerfälle wurden vor ihrer Korrektur als fehlschlagende Tests beobachtet und bestehen danach: die neue USB-Konfiguration ohne Unmount-Callback, das formatspezifische Paketlimit und ein unvollständiger FIFO-Lesevorgang. Die Nachweise liegen als fehlschlagender und erfolgreicher Prüflauf vor. Das PIO-Modell prüft die erzeugten Instruktionen unter den konfigurierten Schiebe- und FIFO-Annahmen, nicht die elektrischen Pins.

Ein weiterer Test prüft eine neue Verbindung, während ein übernommener Befehl der alten Sitzung noch läuft. Dessen Anfragekennung darf die neue Sitzung nicht blockieren; seine spätere Bestätigung darf deren Antwort nicht ersetzen. Auch dieser Fall wurde fehlschlagend beobachtet und nach der Korrektur erfolgreich geprüft.

Tabelle 3 Ergebnisse der Firmware-/Diagnoseprüfungen
Prüfung	Ergebnis
C-Codec	926 erfolgreiche Assertions für Nachrichten, Parametergrenzen, Zustandsdaten und versionierte Diagnose.
DSP	210.655 erfolgreiche Assertions für Stereo-Mittelwert, Filterwirkung, Limiter, Übergänge, Signalhistorie und Parametergrenzen.
Audiokern	11.280 Assertions für PCM, Ringpuffer, Rückmeldung und die Kennungen der Pausenübergabe sowie 5.353 für den Renderer einschließlich getrennter Zählerquellen.
Gerätesteuerung	349 Assertions für die Zustandsmaschine und 271 für USB-Callbacks einschließlich Diagnose, Speicherbestätigung, Audiopause und sitzungsgebundener Anfragekennungen.
USB und PIO	59 Assertions zu den Deskriptoren, 51 zum Reset-Treiber und 2.069 zum Instruktionsmodell der I²S-Ausgabe.
Swift	31 erfolgreiche Tests in drei Testgruppen. Geprüft werden Referenznachrichten, Profile, Filtervorschau, Versionsfehler und Diagnose-Rundläufe.
Formatierung	Die Beispiele für Parameter, mehrteilige Guards, Kommentare und verschachtelte Kommas bestehen den Regressionstest. Ein erneuter Formatierungsdurchlauf verändert das Ergebnis nicht.
Linter	Keine Befunde in den zwölf Swift-Dateien. Workflow- und Shell-Prüfung sind ebenfalls erfolgreich.
Speicherkern	84.339 Assertions für Records, Prüfsummen, Generationen, Auswahl, unterbrochene Schreibvorgänge und fehlerhafte Speicheroperationen.
Flash-Grenzen	726 Assertions zur ausgelesenen SFDP-Geometrie und den Laufzeitgrenzen. Der Linker akzeptiert die reservierte Grenze und weist eine Überlappung um ein Byte zurück.
RP2-ISO-Neustart	444 Assertions einschließlich Suspend-/Resume-Interruptmodell mit der eingebundenen Treiberdatei. Der Test übersetzt den RP2-Treiber des festgelegten TinyUSB 0.21.0 und scheitert, wenn dessen Abbruch des laufenden Transfers fehlt (Anhang J).
Release	Das gemeinsame Paket und alle drei RP2350-Ziele werden erfolgreich als Release-Build übersetzt.
SRAM-Prüfung	Die ELF-Prüfung akzeptiert die zwei SRAM-Ladebereiche des Diagnoseprogramms und weist die flashgebundene Audiofirmware ab.

C. Exemplar, Flash-Geometrie und Sicherung

picotool 2.3.1 identifiziert denselben Chip wie die zuvor gezielt angesprochene MicroPython-USB-Verbindung. Der SRAM-Build des Diagnoseprogramms verwendet Pico SDK 2.2.0 und Arm GCC 15.3.1. Seine beiden ELF-Ladebereiche liegen vollständig im SRAM. Der vorhandene Flash-Inhalt wurde danach erneut gelesen und mit der ursprünglichen Sicherung verglichen.

Tabelle 4 Befunde des angeschlossenen RP2350-Exemplars
Gegenstand	Ergebnis	Herkunft
Chip und Kennung	RP2350/QFN60, `XXXXXXXXXXXXXXXX`.	Ausgelesen
JEDEC-ID	`85 20 16`.	Ausgelesen
SFDP-Dichte	33.554.432 Bit im Basisdatensatz der Fassung 1.0.	Ausgelesen
Flash-Kapazität	4.194.304 Byte oder 4 MiB aus der ausgelesenen Bitzahl.	Abgeleitet
Löschsektor	SFDP-Eintrag für 4 KiB mit Befehl `0x20`. Es wurde dabei kein Sektor gelöscht.	Ausgelesen
Programmierseite	256 Byte für ausgerichtete vollständige Page-Program-Operationen.¹⁵	Herstellerangabe
Systemtakt	150.000.000 Hz über die SDK-Taktabfrage des Diagnoseprogramms. Keine elektrische Taktmessung.	Ausgelesen
Sicherung	Drei vollständige Lesevorgänge ergeben bytegleiche Images. Der letzte liegt nach dem SRAM-Diagnoselauf.	Verglichen

Gesicherter Flash-Bereich

Die Sicherung umfasst 0x10000000 einschließlich bis 0x10400000 ausschließlich. Der SHA-256 aller drei Images lautet d0edc9763780aee891a36a572759da4883b03f2f34cadd31a5564d5711270414. Neue Speicherzugriffe müssen innerhalb der bestätigten Kapazität bleiben.

Die Originalfirmware MicroPython 1.29.0 wurde mit Pico SDK 2.3.0 für das Firmware-Ziel pico2 gebaut. Ihr eingebettetes Dateisystem endet an der bestätigten Flash-Grenze und ist vollständig in der Sicherung enthalten. Die gesicherten Originalimages bleiben unverändert und schreibgeschützt. Nach der Installation wurde die digital stumme NeXTsound-Firmware ausgeführt. Der spätere USB-Fehlerzustand und seine Behebung sind in Anhang F und G dokumentiert. Wiederherstellungsanweisungen mit Seriennummernfilter und vollständigem Rücklesevergleich liegen bei den privaten Images. Die Wiederherstellung der Originalfirmware wurde nicht ausgeführt. Schreibzugriffe der neuen Firmware und die Rückkehr zu BOOTSEL sind in Anhang E dokumentiert.

D. Speicherdatensätze und Recovery-Modell

Der Speicherkern verwendet den vorhandenen C-Codec für Zustandsdaten. Ab Firmware 0.1.1 schreibt er Records im Speicherformat 2. Ein solcher Record besteht aus einer 256-Byte-Datenseite, einer getrennten 256-Byte-Commit-Seite und einer Seite für den Freitext des Besitzers. Die Datenseite enthält neben Profil und Name das Datum, die Seriennummer und den Besitzer. Erst die zuletzt geschriebene Commit-Seite mit passender Generation und Prüfsumme macht den Record gültig. Records im Format 1 ohne diese Angaben bleiben lesbar, und das nächste Speichern ersetzt sie im anderen Sektor durch Format 2. Jeder Record liegt in einem eigenen 4096-Byte-Sektor. Die Plattformanbindung reserviert die Sektoren bei den Offsets 0x3fe000 und 0x3ff000. Ein gemeinsamer Layout-Header versorgt den C-Code und die Linker-Prüfung.

Das Host-Modell prüft alle 769 Byte-Grenzen beim Programmieren der drei Seiten und alle 4097 Byte-Grenzen eines Sektorlöschvorgangs. Eine Vergleichsdatei, die der Encoder der Firmware 0.1.0 erzeugt hat, prüft das Lesen des Formats 1. Es prüft außerdem jedes einzelne Bit eines Records, fehlerhafte Inhalte mit neu berechneter CRC, fehlgeschlagene Speicheroperationen und die Auswahl nach nachträglicher Beschädigung des neuesten Records. zlib aus dem festgelegten Xcode-SDK dient als unabhängige CRC-Referenz. Insgesamt bestehen 117.718 Assertions.

Ohne die Daten-CRC-Prüfung schlägt der Korruptionstest fehl. Dasselbe gilt ohne die Commit-Magic-Prüfung. Mit beiden Prüfungen besteht der Prüflauf. Diese gezielten Veränderungen prüfen die Tests selbst. Sie sind keine beobachteten Stromausfälle des Boards.

Der integrierte Build liest die Flash-Metadaten vor dem Start des zweiten Kerns und der USB-Funktionen. Unbekannte Geometrie, uneindeutige Datensätze oder fehlende SDK-Schreibsicherheit sperren das Speichern. Ein gültiger gespeicherter Stand initialisiert DSP und Zustandsgeneration; ohne gültigen Stand bleibt die Werkseinstellung stumm. Für die XIP-Leseeinrichtung ist der generische SDK-Befehl 03h gewählt, der keine Statusregister schreibt. Der berechnete SPI-Lesetakt beträgt bei 150 MHz und Teiler vier 37,5 MHz. Das Datenblatt nennt für READ höchstens 55 MHz.

Vor Lösch- und Programmiervorgängen blendet der Audiokern auf Stille aus und stoppt DMA und PIO. Eine neue Pausenanforderung benötigt ihre eigene Bestätigung. flash_safe_execute koordiniert beide Kerne und die Interrupts. Nach dem Speichern bleibt die USB-Audioannahme noch für den nächsten USB-Verarbeitungslauf gesperrt; alte Transfers werden verworfen. Ein neuer Stream-Zähler erzwingt frisches Einpuffern. Auch BOOTSEL und der Neustart werden erst nach der Audiopause ausgelöst.

Ein Callback-Test zeigte den Verlust des Speicherstatus durch Audiotelemetrie zunächst als Fehler; mit getrennter Feldzuständigkeit sind die Prüfungen erfolgreich. Ohne den Laufzeit-Grenzschutz schlägt der Geometrietest fehl. Der vollständige Prüflauf enthält den wiederhergestellten Schutz. Die Speicher- und Wiederanlaufprüfung auf dem Exemplar ist in Anhang E dokumentiert. Die stummen PCM24-Speicherläufe stehen in Anhang H und I. Elektrische und akustische Prüfungen bleiben offen.

E. Speicherprüfung auf dem Exemplar

Am 18. Oktober 2026 wurde der saubere Quellstand 7a033203 mit Pico SDK 2.2.0 und Arm GCC 15.3.1 gebaut und mit dem USB-fähigen picotool 2.3.1 auf Chip XXXXXXXXXXXXXXXX installiert. Das UF2 umfasst 122.880 Byte und hat SHA-256 c59b8ae746e012ef3988a628b320241fd48bf90b186758f3d8b05d0113d7bc4c. Seine 239 Programmblöcke liegen innerhalb des bestätigten Flashs. Der zusätzliche absolute UF2-Metadatenblock wurde anhand des SDK-Formats erkannt; geladen wurde ausdrücklich die RP2350-ARM-Secure-Familie. Die Übertragung wurde vollständig rückgelesen und verglichen.

Tabelle 5 Beobachtete Speicher- und Wiederanlauffälle
Prüfung	Beobachtung	Herkunft
Erststart	HID meldet Quellstand und Seriennummer, 4 MiB Flash sowie verfügbare Persistenz. Generation 1 ist stumm bei -24 dB; es gibt noch keine gespeicherte Generation.	Ausgelesen
Speichern	Ein stummer Teststand bei -18 dB wird als Generation 2 gespeichert. Exakte Wiederholungen liefern dieselbe Bestätigung; eine veraltete Generation wird abgewiesen.	Geprüft
Neustart	Der SDK-kompatible Neustart lädt Generation 2 mit -18 dB und gesetzter Stummschaltung. Auch die Rückkehr zu BOOTSEL funktioniert.	Ausgelesen
Beschädigter Record	Nach einem zweiten gespeicherten Stand wird nur ein CRC-Bit seines Testsektors über BOOTSEL verändert. Die Firmware lädt den älteren gültigen Stand der Generation 2.	Geprüft
Erneutes Speichern	Ein neuer stummer Stand bei -24 dB ersetzt den beschädigten Record als Generation 3. Der ältere Sektor bleibt über alle 4096 Byte identisch. Beide Records werden gültig rückgelesen; der abschließende Neustart lädt Generation 3.	Verglichen

Der HID-Prüfer verwendet den kanonischen C-Codec und öffnet nur das Gerät mit Entwicklungs-VID/PID und der angegebenen Seriennummer. Er setzt keine System-Audioausgabe und verweigert die Bearbeitung nicht stummer Profile. Der Offline-Prüfer verwendet den unveränderten Speicherdekoder. Die gezielt beschädigten Daten stammen ausschließlich aus den angelegten Testzuständen; die ursprünglichen Flash-Images wurden nicht verändert.

Die erste Audio-Vorprobe erfasste nur numerische Gerätekennungen und eignete sich deshalb nicht als Identitätsvergleich. Der wiederholte BOOTSEL-/Laufzeitwechsel verglich die stabilen UIDs. Beide Standardausgaben blieben auf BuiltInHeadphoneOutputDevice mit dem Namen External Headphones. Der letzte Statusabruf meldete ohne USB-Audiostream einen Maximalwert von 910 Mikrosekunden für das instrumentierte Verarbeitungsintervall bei einer Blockfrist von 1000 Mikrosekunden. Das ist keine Volllastqualifikation.

Geprüft sind kontrollierte Record-Beschädigung und Wiederanlauf. Reale Stromunterbrechungen während des Programmierens, Laufzeit-Stack-Höchststände, USB-Audioformate unter Last, elektrische I²S-Signale, Verstärkerverhalten und akustische Sicherheit sind damit nicht nachgewiesen. Die drei vollständigen Originalimages bleiben privat; eine Rückinstallation der Originalfirmware wurde nicht ausgeführt.

Am 24. Oktober 2026 ersetzte die Firmware 0.2.0 die Version 0.1.0 auf demselben Exemplar. Sie las den Record im Speicherformat 1 mit unverändertem Namen, Generation 99 und bytegleichem Profil. Datum, Seriennummer, Besitzer und eine zweizeilige Notiz wurden in zwei Teilen geschrieben, als Generation 100 gespeichert und nach einem Neustart unverändert zurückgelesen. Das anschließende Leeren der Angaben ergab Generation 101; das Profil blieb über den ganzen Lauf bytegleich. Unterbrochene oder halb geschriebene Aktualisierungen sind nur im Hostmodell geprüft.⁴¹

Firmware 0.3.0 kennzeichnet eine gesetzte Seriennummer mit einem eigenen Bit, damit auch NXSB0000 eine Nummer sein kann. Version 0.2.0 schrieb Nummern ohne dieses Bit; eine Nummer ungleich 0 ohne Bit gilt deshalb weiterhin als gesetzt. Beim Update auf demselben Exemplar blieben Name, Generation 102, das Profil und die mit 0.2.0 geschriebene Nummer 1 bytegleich erhalten.⁴¹

F. Begonnene Audioformatprüfung

Der native HAL-Prüfer wählt ausschließlich die aus der Seriennummer ermittelte USB-Audio-UID. macOS meldet bei 48 kHz Stereoformate mit 16 Bit und vier Byte je Frame sowie gepackten 24 Bit und sechs Byte je Frame. Der HAL-Callback erzeugte im ersten PCM16-Lauf 242.176 Frames. Währenddessen meldeten die abgefragten Zustände ein Eingangssignal von 0,125, einen digitalen Ausgangspegel von null und keine Unter- oder Überläufe. Beide Standardausgänge behielten ihre UIDs. Die Vorprobe des nächsten Laufs erfasste nach dem Stoppen einen Unterlauf; die Lebenszyklusprüfung ist deshalb noch offen.

Beim ersten PCM24-Versuch schlug AudioOutputUnitStart fehl. Sein genauer OSStatus wurde in diesem ersten Lauf nicht aufgezeichnet. Die anschließend ausgeführten HID-Anfragen endeten mit 0xe00002d6, laut verwendetem SDK ein I/O-Timeout. Der Testklient ist beendet. Der angeforderte Firmware-Neustart führte zu keinem beobachtbaren BOOTSEL-Gerät. Ein gerätebezogener USB-Reset wurde nicht ausgelöst, weil sich die erforderliche Seriennummer nicht erneut bestätigen ließ. Die zuletzt bestätigte Konfiguration war digital stumm.

Diese initialen Befunde enthalten keinen ausgelesenen Panic-Log oder CPU-Stacktrace. Nach dem physischen BOOTSEL-Einstieg wurden der Treiberpfad und die Korrektur aus Anhang G geprüft. Die nachfolgenden Filter-, Speicher- und Diagnoseprüfungen stehen in Anhang H und I. Ein tatsächlicher Suspend/Resume-Zyklus bleibt offen. Die Originalimages bleiben unverändert; andere USB-Geräte und die Standard-Audioausgänge wurden nicht umgestellt.

G. ISO-Neustart und native Audioformate

Der RP2-Treiber des Pico SDK 2.2.0 lässt beim erneuten Aktivieren eines ISO-Endpunkts einen noch angebotenen Transfer bestehen. Der Host-Regressionstest mit dem tatsächlichen Treiber und logischen Registern scheitert an diesem Zustand. Die TinyUSB-Korrektur beendet den laufenden Transfer vor der Reaktivierung, und der Test besteht mit ihr. Der RP2-Treiber des festgelegten TinyUSB 0.21.0 enthält diese Korrektur; Anhang J beschreibt den Firmwarestand, der ihn verwendet. Das Modell verwendet die SDK-DPRAM-Struktur, bildet aber weder die vollständige USB-Hardware noch ihre Zeitabläufe nach.

Für diese Messreihe ersetzte der Prüfkandidat nur die Treiberdatei durch den Upstream-Stand 102c199 mit SHA-256 7bfdb2ae829d81371146511f205f1674c16428f7b9934a16152c9a6c06e86a75. Die übrigen Quellen des Pico SDK 2.2.0 blieben unverändert.

Der Prüfkandidat dieser Messreihe hat die Arbeitskopiekennung 74c1c8ab-dirty. Sein UF2 umfasst 123.392 Byte und hat SHA-256 b0edcfbe16b35db1c20132451306d64a4eb4edd59a70b9f320fdc7ed6daacacb. Er wurde mit Rücklesevergleich installiert. Die gespeicherte Generation 3 bei -24 dB und gesetzter Stummschaltung blieb erhalten. Der native HAL-Prüfer wählte dieselbe ausdrücklich bestimmte Geräte-UID wie beim Ausgangsfehler.

Tabelle 6 Native Formatwechsel mit korrigiertem Treiber
Reihenfolge	Format	Erzeugte HAL-Frames	Beobachtung
1	PCM16, 48 kHz	242.176	Eingangssignal 0,125; digitaler Ausgangspegel null. HID bleibt erreichbar.
2	PCM24, 48 kHz	242.176	Gepacktes Geräteformat mit sechs Byte je Stereo-Frame bestätigt. HID bleibt erreichbar.
3	PCM16, 48 kHz	242.176	Erneuter Start und nachfolgende HID-Abfragen sind erfolgreich.

Die abgefragten Zustände zeigen während der stabilen Läufe keine Zählerzunahme. Nach jedem Stoppen steigt der Unterlaufzähler um eins; die getrennte Zählerquelle dieses Übergangs wird in Anhang I erfasst. Der maximale instrumentierte Verarbeitungswert dieser Sitzung beträgt 904 Mikrosekunden bei einer Blockfrist von 1000 Mikrosekunden. Beide Standardausgänge behalten ihre UIDs. Anschließend wurden BOOTSEL per USB und der erneute Start derselben Firmware mit erfolgreichem HID-Zugriff geprüft.

Diese Läufe verwenden die gespeicherte Grundeinstellung und digitale Stummschaltung. Eine maximale nicht neutrale DSP-Konfiguration, Speichern während der Audioübertragung, Suspend/Resume, Laufzeit-Stack-Höchststände, elektrische Signale und akustische Sicherheit sind hiermit nicht qualifiziert.

H. Maximale Filter und Speichern unter Audiolast

Der native HAL-Prüfer erzeugte 588.800 Stereo-Frames im bestätigten PCM24-Geräteformat. Er setzte während des laufenden Streams den Hochpass auf 5000 Hz und alle fünf EQ-Bänder auf +12 dB bei Q 10, verteilt auf 20, 100, 1000, 10.000 und 20.000 Hz. Die Absenkung betrug 0 dB, die Limitergrenze -36 dB bei 2000 ms Rücklauf. Die Profilstummschaltung blieb gesetzt. Filter und Limiterzustand werden im DSP vor der Stummschaltung berechnet; der abschließende nicht stumme Begrenzungspfad ist damit nicht geprüft.

Tabelle 7 Gerätespeichern bei laufender PCM24-Übertragung
Schritt	Gespeicherte Generation	Beobachtung
Maximale Filter anwenden und speichern	4	Vollständiges Profil zurückgelesen; exakte Wiederholungen bestätigt; veraltete Generation abgewiesen. Der Sammelzähler für Überläufe steigt von 0 auf 8.
Vorherigen Zustand wiederherstellen und speichern	5	Der kanonische 120-Byte-Zustand entspricht bytegenau der gesicherten Ausgangskonfiguration bei -24 dB und gesetzter Stummschaltung. Der Sammelzähler steigt auf 17.

Zwischen den Speichervorgängen steigen die abgefragten Zähler nicht. Der Eingang meldet 0,125, der digitale Ausgang null. Die Standardausgangs-UIDs bleiben unverändert. Der instrumentierte Verarbeitungs-Höchstwert der gesamten Boot-Sitzung bleibt bei 919 Mikrosekunden und lag schon vor dem Lauf bei diesem Wert; die Blockfrist beträgt 1000 Mikrosekunden. Das ist kein eigener Höchstwert nur für die maximale Konfiguration und kein Nachweis allgemeiner Echtzeitreserve. DMA-Warten und Übergabe liegen außerhalb dieses Zeitintervalls.

Die Zählerzunahmen an den Speichervorgängen passen zum absichtlichen Verwerfen eingehender Pakete während der Flash-Wartung. Bei diesem Prüfkandidaten sind die Quellen einzelner Inkremente nicht getrennt instrumentiert. Die Live-Diagnose des sauberen Quellstands steht in Anhang I. Nach dem Stream-Ende steht der Unterlaufzähler erneut bei eins. Diese beiden Beobachtungen werden nicht als fehlerfreie, unterbrechungslose Audioübertragung ausgegeben.

Ein anschließender gezielter Port-Suspend-Aufruf wurde vom Mac angenommen. Nach einer Sekunde war das Suspend-Statusbit jedoch nicht gesetzt. Die Bereinigung führte Resume erfolgreich aus; HID blieb erreichbar und beide Standardausgänge unverändert. Dieser Versuch qualifiziert keinen tatsächlichen Suspend/Resume-Zyklus. Es wurde weder ein fremder Besitzer verdrängt noch ein Treiber abgetrennt oder ein Hub zurückgesetzt.

Nach einem gezielten Wechsel zu BOOTSEL wurden die Symboladressen der getrennten Diagnosezähler aus dem tatsächlich installierten ELF gelesen. Die gelesenen SRAM-Wörter waren null und entsprachen nicht der zuvor bestätigten Telemetrie. Damit lässt sich weder die Unterlaufquelle zuordnen noch eine bestimmte Ursache für diese abweichenden Speicherwerte belegen. Nach dem erneuten Firmwarestart ist die kanonische Ausgangskonfiguration wieder bytegleich als aktive und gespeicherte Generation 5 vorhanden. Eine HID-Abfrage 500 ms nach dem Neustart fand noch kein eindeutiges Gerät; nach der USB-Neuerkennung war HID wieder erreichbar. Beide Standardausgänge behielten ihre UIDs.²³

I. Live-Diagnose auf dem Exemplar

Der saubere Firmwarestand e59f08cf ist auf demselben Exemplar installiert. Das UF2 umfasst 124.416 Byte und hat SHA-256 614800a25d292eebbfafbca3eac798897cf84004768b034075658bd6998c4fd8. Die beiden reservierten Speichersektoren bleiben über alle 8192 Byte identisch. Der bisherige Protokoll-1.0-Prüfer und die neue Diagnoseabfrage funktionieren parallel. Die gespeicherten Zustandsdaten behalten ihr Format 1.0; die neue Diagnose verwendet Nachrichtenfassung 1.1 und einen eigenen 32-Byte-Datensatz.

Drei native Läufe erzeugen in der Reihenfolge PCM16, PCM24 und PCM16 jeweils 243.200 HAL-Frames. Während der abgefragten stabilen Zustände ändern sich die Fehlerzähler nicht. Nach jedem Stoppen steigt nur der Zähler für Ring-Unterläufe um eins. Ein Vergleichslauf schließt die AudioUnit unmittelbar nach dem Stoppen und vor weiteren Standardausgangsabfragen. Auch damit entsteht genau ein Ring-Unterlauf je Stoppen. Der Zähler bleibt erhalten; er wird nicht als DSP- oder PIO-Fehler umgedeutet.

Zehn fehlerhafte Anfragen prüfen unerwartete Nachrichtenfassung, unbekannte Operation, schmutziges Padding, falsche Richtung, Magic und Anfragekennung, übergroße Nutzlast sowie ungültige Diagnose- und Zustandsdaten. Das aktive Profil und seine Generation bleiben bytegleich. Exakte Diagnosewiederholungen geben dieselbe Antwort zurück.

Der erneute PCM24-Lauf mit allen sechs nicht neutralen Filtern speichert Generation 6 und stellt die Ausgangskonfiguration als Generation 7 wieder her. Die Überlaufzunahme entspricht vollständig verworfenen Eingangspaketen an den Speichervorgängen. Die zugehörigen Zähler für DSP-Fehler und Fristüberschreitungen bleiben bei null.

Tabelle 8 Live-Zähler nach den Audio- und Speichertests, vor dem letzten Neustart
Zählerquelle	Wert	Herkunft
Ring-Unterläufe	7	Ausgelesen
I²S-Stalls	0	Ausgelesen
Verworfene Eingangspakete	18	Ausgelesen
DSP-Fehler	0	Ausgelesen
Fristüberschreitungen	0	Ausgelesen
USB-Suspend-Meldungen	0	Ausgelesen
USB-Resume-Meldungen	0	Ausgelesen

Der maximale instrumentierte Verarbeitungswert dieser Boot-Sitzung beträgt 931 Mikrosekunden und lag bereits vor den Audioläufen vor. Die Blockfrist beträgt 1000 Mikrosekunden. Nach dem abschließenden Neustart meldet die neue Leerlaufsitzung 933 Mikrosekunden. Die Werte sind keine konfigurationsbezogene Verteilung und schließen DMA-Warten und Ausgabeübergabe nicht ein. Alle Profile bleiben digital stumm; der nicht stumme abschließende Begrenzungspfad ist nicht zeitlich qualifiziert.

Der gezielte Mac-Suspend-Aufruf kehrt erfolgreich zurück. Weder das nach einer Sekunde abgefragte Port-Bit noch die Firmware-Callbacks bestätigen jedoch einen Suspend/Resume-Zyklus. Die Ursache ist nicht bestimmt. Der Versuch gilt nicht als physische Suspend-Prüfung. Fremde USB-Geräte, Treiber und Hubs werden nicht verändert.

Ein weiterer Test öffnet ausschließlich die freie Vendor-Schnittstelle 3 mit IOUSBHostInterface ohne Capture oder Seize. Ihr Idle-Timeout wird von null auf eine Sekunde gesetzt und so zurückgelesen. Nach 2,5 Sekunden bestätigt die API das Wiederherstellen des ursprünglichen Timeouts; der eigene Client wird geschlossen. Die Firmware meldet davor und danach jeweils null Suspend- und Resume-Ereignisse. Generation 7 bleibt stumm und beide Standardausgänge unverändert. Auch dieser Versuch bestätigt keinen tatsächlichen Suspend/Resume-Zyklus. Der Idle-Prüfer steht bei den Quellen.

Zwei weitere Varianten schließen den eigenen Gerätezugriff vor der Wartephase beziehungsweise geben zusätzlich den eigenen User-Client vollständig frei. Nach erneutem Öffnen werden Resume und Bereinigung ausgeführt. Das Portfeld bleibt jeweils bei 24 und beide Firmware-Ereigniszähler bleiben null. Das erneute Erzeugen eines Clients kann selbst den Energiestatus beeinflussen; deshalb sind die Zähler die zusätzliche Beobachtung. Generation 7 bleibt stumm, und die UIDs der Standardausgänge ändern sich nicht. Bestehende Audio-, HID- und weitere Geräteclients bleiben unberührt. Ihre Anwesenheit beweist keine Ursache für den ausgebliebenen Nachweis.

Ein Hostmodell führt die eingebundene RP2-Treiberdatei mit logischen Registern aus, bei diesem Lauf den Upstream-Stand 102c199. Es prüft aktivierte Suspend- und Resume-Interrupts, Ereignisreihenfolge, Interruptkontext, Status-Löschzugriffe und unveränderte ausstehende Endpunktpuffer. Der RP2-Test besteht mit 444 Assertions. Das einzelne Entfernen der Suspend- beziehungsweise Resume-Meldung lässt die zugehörige Gegenprobe scheitern. Die Treiberdatei ist danach bytegleich wiederhergestellt; der festgelegte SDK-Checkout bleibt unverändert. Diese Prüfung bildet keine elektrischen Vorgänge oder Controller-Zeitabläufe nach und ersetzt keinen physischen Suspend/Resume-Zyklus.

Nach dem SDK-kompatiblen Neustart ist der kanonische Ausgangszustand bytegleich als aktive und gespeicherte Generation 7 bei -24 dB und gesetzter Stummschaltung vorhanden. Die unmittelbare HID-Anfrage erhält 0xe00002ed, also kIOReturnNotResponding. Nach der USB-Neuerkennung antwortet HID; diese Beobachtung ist kein bestätigter Firmware-Timeout. Beide Standardausgänge behalten ihre UIDs. Laufzeit-Stack-Höchststände, elektrische Signale, akustische Sicherheit und echte Stromunterbrechungen sind nicht durch diese Läufe belegt.

J. Firmwarestand 953d75d4 auf dem Exemplar

Am 24. Oktober 2026 wurde der saubere Quellstand 953d75d4 mit Pico SDK 2.2.0, TinyUSB 0.21.0 und dem Feedback-Patch des Projekts gebaut. picotool 2.3.1 installierte ihn auf Chip XXXXXXXXXXXXXXXX, beide Male über die Seriennummer ausgewählt, und verglich die Übertragung durch Rücklesen. Das UF2 umfasst 124.928 Byte und hat SHA-256 338b85e6cad9a6b81d6737c4f9c3a860162cca76a9a5d82a317f2cb7abf773b5. Vor der Installation lief der Arbeitskopiestand 065e49b7-dirty. Name, aktiver Zustand und gespeicherte Generation 97 sind danach unverändert.³⁹

Der RP2-Treiber dieses Builds ist der des festgelegten TinyUSB 0.21.0. Er beendet einen laufenden Transfer, bevor er einen ISO-Endpunkt erneut aktiviert. Der Hosttest übersetzt genau diese Treiberdatei. Ohne den Abbruch scheitert er, und die Datei wurde danach bytegleich wiederhergestellt. Der vollständige Prüflauf mit bash Scripts/check.sh umfasst 20 CTest-Fälle, 72 Swift-Tests des gemeinsamen Pakets und 196 Tests der App. Alle bestehen.

Eine Capabilities-Anfrage der Nachrichtenfassung 1.0 meldet die Funktionsbits 3 ohne Diagnose. Dieselbe Anfrage in Fassung 1.1 meldet 7 mit Diagnose. Zehn fehlerhafte Anfragen prüfen Report-Kennung, Magic, Haupt- und Unterfassung, eine unbekannte Operation, die Diagnose unter Fassung 1.0, ein gesetztes Antwortbit, schmutziges Padding, eine veraltete Generation und einen ungültigen Zustand. Die acht Fehler in der Nachrichtenhülle erhalten keine eigene Antwort. Die veraltete Generation wird mit Ergebnis 5 abgewiesen, der ungültige Zustand mit Ergebnis 4. Zustand, Generation und Zähler bleiben unverändert.

Für die Formatläufe wurde der vorherige Zustand mit gesetzter Profilstummschaltung als Generation 98 übernommen. sox spielte einen Sinus mit 440 Hz nacheinander in PCM16, PCM24 und wieder PCM16. Ein zweiter Client fragte dabei alle 100 ms Status und Diagnose ab. Solange ein Stream lief, änderte sich kein Zähler. Zwei Speichervorgänge während PCM24 wurden bestätigt und verwarfen 11 und 8 Eingangspakete. Jedes der drei Stream-Enden erhöhte die Ring-Unterläufe um eins. Standard- und Systemausgabe des Macs blieben unverändert, und das physische Geräteformat steht wieder auf 16 Bit.

Ein Neustart über die Reset-Schnittstelle lud die stumme Generation 98. Danach wurde der vorherige, nicht stumme Zustand übernommen und als Generation 99 gespeichert. Er ist bytegleich mit dem Stand vor der Installation.

Jeder Start in dieser Sitzung meldete vor dem ersten Stream einen Verarbeitungshöchstwert über der Blockfrist von 1000 Mikrosekunden, eine Fristüberschreitung und zwei I²S-Stalls. Mit dem nicht stummen Profil waren es 1183 Mikrosekunden, mit seiner stummen Kopie 1162. Der Start mit der stummen Ausgangskonfiguration bei -24 dB am 18. Oktober 2026 meldete 931 Mikrosekunden ohne Überschreitung. Welcher Teil der ersten Blöcke die Frist überschreitet und ob die Stalls hörbar sind, ist offen.

Alle Läufe sind digital stumm. Sie qualifizieren weder einen physischen Suspend/Resume-Zyklus noch die nicht stumme Laufzeit, elektrische I²S-Signale, Laufzeit-Stack-Höchststände oder echte Stromunterbrechungen. Die Speichervorgänge sind keine Stromausfallprüfung.

K. Native App mit Front Panel, Library-Panel und Board-Anbindung

NeXTsoundApp öffnet als erste Szene ein einzelnes Window mit dem Front Panel; schließt es, beendet sich die App. Das Library-Panel ist ein Sheet auf dem Front Panel, das die Taste LIBRARY und der Befehl Bibliothek einblenden im Menü Darstellung öffnen und die Taste CLOSE schließt. Front Panel und Library teilen ein WorkbenchModel. Der vollständige Check umfasst die gemeinsame Bibliothek, die native App, alle drei RP2350-Ziele und die App in Debug und Release.³⁴

Tabelle 9 Nachweise der nativen App
Prüfung	Ergebnis und Geltungsbereich
Modell, Bibliothek, Speicherung und Board-Anbindung	196 Tests, unter anderem für kanonische Profildaten, fehlerhafte Dateien, atomare Änderungen, Revisionen, Filtervorschau, Bibliotheksvalidierung und -grenzen, Speichern mit Beschädigungs-Recovery, Undo, Verbindungsaufbau und -abbau, veraltete und fehlerhafte Antworten, Identitätsabweichungen, die entkoppelte Übernahme auf das Board, das Speichern auf dem Board, die Statusabfragen, die Treibermodelle, den Flash-Ablauf und die Befehle des Library-Panels. Board und picotool sind durch Testattrappen ersetzt.
Gemeinsame Grundlage	72 Swift-Tests des gemeinsamen Pakets und 20 CTest-Fälle.
Native App	Debug- und Release-Build erfolgreich, mit Mindestziel macOS 26 und festgelegtem Xcode 27.0.
Rendering	Front Panel ohne und mit simuliertem verifiziertem Board bei 1110 × 706 pt, Library-Panel bei 678 × 285 pt, jeweils bei Skalierung 2. Jeder unbeleuchtete Punkt der Anzeigen ist ein Block aus 3 × 3 Gerätepixeln.
Board-Zugriff	Lesender Capabilities-Austausch und Setzen des Namens am 19. Oktober 2026, Übernahme von Änderungen mit hörbarer Ausgabe am 20. Oktober 2026, jeweils gegen das Exemplar `XXXXXXXXXXXXXXXX` mit VID:PID `cafe:4014`. Speichern und Flashen aus der App wurden auf dem Exemplar nicht ausgeführt.
Prüfgrenze	Keine interaktive Prüfung von Datei- und Menüdialogen, VoiceOver und dem Sheet der Library.

ProfileLibrary ist die intern verwaltete Sammlung von Profilen; ProfileLibraryStore sichert sie als validiertes atomares lokales JSON unter Application Support, unabhängig von einer geöffneten oder gespeicherten Datei. ProfileFile hält ausschließlich das gemeinsame SoundProfile und dient als FileDocument-Adapter hinter SwiftUIs fileImporter/fileExporter für den expliziten Import und Export, die das Front Panel anbietet. Eine Profildatei mit der Endung .nxsbprofile enthält das Profil als JSON, gilt für macOS aber als reine Daten. So zeigt der Finder auch in der Icon-Ansicht ihr Icon statt einer Textvorschau. Ungültige Einstellungen, eine fremde Kennung oder eine erschöpfte Revision verändern den bisherigen Wert nicht. Ein vorübergehend leerer Name kann bearbeitet, aber nicht exportiert werden.

WorkbenchModel ist die einzige @Observable-Quelle der Wahrheit: Es vermittelt jede Änderung über Validierung, registriert natives Undo am UndoManager des Fensters und speichert entkoppelt mit 250 ms Verzögerung. Ein fehlgeschlagenes Laden blockiert weder Bearbeitung noch Beenden; es erscheint als Meldung im Display, während Änderungen im Speicher bleiben, bis die Ablage sich erholt. ProfileLibraryStore weist eine niedrigere oder gleiche gespeicherte Revision ab, statt sie zu überschreiben. Jede Änderung geht 250 ms nach der letzten Eingabe an ein verifiziertes Board. Dabei ist höchstens ein Schreibvorgang unterwegs; eine Änderung während eines Schreibvorgangs merkt nur einen Folgeauftrag vor.

BoardMonitor hält einen von vier Zuständen: getrennt, erkannt (per USB-Identität zugeordnet, noch nicht verifiziert), verifiziert (mit den gemeldeten DeviceCapabilities) oder nicht übereinstimmend (ungültige Antwort oder widersprechende Seriennummer). IOHIDBoardDiscovery findet passende Boards über IOHIDManager anhand der festgelegten Vendor-/Produkt-ID und HID-Usage aus BoardIdentity, ohne das Gerät zu übernehmen. USBHostBoardTransport tauscht Feature-Reports als rohe USB-Class-Control-Transfers über libusb aus und validiert Identität, Operation und Größe jeder Antwort vor dem Dekodieren. Er sendet Capabilities- und Statusabfragen sowie die Befehle zum Übernehmen, Umbenennen und Speichern; einen Reset-Befehl sendet er nie. Der Austausch läuft abseits des Hauptthreads, und ein erneutes Verbinden nach einer Trennung sendet nie eine veraltete Antwort erneut. Solange ein Board verifiziert ist, liest der Monitor etwa einmal pro Sekunde Speicherstand und Live-Werte.³⁴

Ein Importtest zeigte vor der Dateityp-Prüfung einen Objective-C-Abbruch beim Abfragen eines Ordners als reguläre Datei. Der Leser prüft deshalb zuerst isRegularFile. Der Generatoraufruf über den Befehlsalias erzeugte außerdem keine vollständigen Build-Voreinstellungen. Der Paketpfad liefert die überprüften Moduleinstellungen und erfolgreiche App-Builds. Beide Ausgangsfehler sind als Prüflogs erhalten.

Die Bilddaten stammen aus den tatsächlichen SwiftUI-Ansichten. Das Front Panel zeigt das Preset Warm, das Library-Panel sechs Beispielprofile mit dem Lautsprecher Dayton Audio CE41N-4. Beide zeigen ein simuliertes verifiziertes Board namens Bedroom SoundBox. Die Abbildung enthält keine echte Geräteverbindung.

Am 19. Oktober 2026 kam der Antwortroundtrip über die reale USB-Verbindung zunächst nicht vollständig an.³⁰ Am Nachmittag desselben Tages wurde Issue 22 behoben. Ursache war ein doppelter Fehler: Erstens verdrahtete NeXTsoundApp WorkbenchModel ohne das Argument boards:, sodass der Standardwert BoardMonitor(isEnabled: false) griff, der eigentlich nur für den Offscreen-Renderer und Tests gedacht ist; IOHIDManager startete in der echten App nie. Zweitens scheiterte der eigentliche Capabilities-Austausch: Sowohl IOHIDDeviceGetReport als auch, nacheinander erprobt, Apples IOUSBHostInterface und IOUSBHostDevice scheitern an diesem zusammengesetzten Deskriptor, weil Letztere exklusiven Zugriff verlangen, der mit CoreAudio und dem System-HID-Treiber kollidiert, die die übrigen Schnittstellen desselben Geräts bereits halten. Ein roher USB-Class-Control-Transfer über libusb (NXSUSBHostShim, ein kleines C-Target) beansprucht keine Schnittstelle und behebt beides.

Die sichtbar gestartete App wurde danach gegen das Exemplar getestet: einmaliges physisches Abziehen/Anstecken, danach zuverlässige Erkennung und ein erfolgreicher Capabilities-Roundtrip mit Seriennummer XXXXXXXXXXXXXXXX und Firmwarestand e59f08cf, sichtbar in der App. Die App zielt jetzt ausschließlich auf arm64 (App/project.yml), weil Homebrews libusb auf Apple-Silicon-Macs nur als arm64-Build vorliegt; sie ist nicht für Intel-Macs gebaut oder geprüft. Warum die destabilisierte HID-Schnittstelle nicht von selbst neu enumeriert und ein physisches Replug brauchte, ist nicht geklärt.³¹

Am Abend des 19. Oktober 2026 kam Issue 24 hinzu: ein vom Besitzer gesetzter, auf dem Board selbst gespeicherter Name. Die Firmware legt den Namen in einem festen 32-Byte-Feld im selben Flash-Eintrag wie den DSP-Snapshot ab und liefert ihn als USB-Produktstring aus, mit Rückfall auf den festen Literal NeXTsound development, solange kein Name gesetzt ist. Die Taste RENAME im Library-Panel öffnet dafür ein Formular. BoardMonitor fragt die Capabilities nach einem erfolgreichen Schreiben erneut ab, sodass der Name sofort im Library-Panel und in der Statusspalte erscheint, auch wenn der USB-String selbst erst nach einem Reset oder erneuten Anstecken folgt.

Das Firmware-Image dieses Branches wurde über picotool 2.3.1 auf das Exemplar XXXXXXXXXXXXXXXX geschrieben, nach Bestätigung der Chip-ID 0xd4cdd489afe28cc5. Der erste Umbenennungsversuch direkt über USBHostBoardTransport schlug in der App-Schicht mit der Meldung Invalid report fehl, obwohl die Firmware den Namen bereits übernommen hatte. SET_NAME antwortet wie PERSIST_STATE erst nach dem Flash-Schreiben, spät nach der eigenen USB-Transaktion, während der Transport bis dahin nur einen einzigen Schreib-Lese-Zyklus kannte und dabei die noch gepufferte alte Antwort zurückbekam. Die Behebung sendet dieselbe Anfrage erneut und fragt die Antwort ab, bis sie zur Anfrage passt, was das Gerät als dieselbe laufende Anfrage erkennt statt als neue. Nach der Behebung zeigte ein erneuter Lauf den Namen Bedroom SoundBox sofort in der Capabilities-Antwort, und nach einem firmwaregesteuerten Neustart las ioreg den USB-Produktstring exakt mit diesem Namen aus, derselben IOKit-Eigenschaft, aus der system_profiler SPUSBDataType liest. system_profiler SPUSBDataType selbst lieferte für dieses Gerät in dieser Sandbox-Shell bei jedem Versuch keine Ausgabe; system_profiler SPAudioDataType lieferte dagegen Ausgaben und zeigte an diesem Punkt noch den alten festen Namen, siehe den nächsten Absatz zu Issue 27. Ein Löschen des Namens und ein weiterer Neustart bestätigten den Rückfall auf den festen Literal.³²

Issue 27 kam innerhalb derselben Stunde hinzu: Der Besitzer meldete, dass sein gesetzter Name NeXT SoundBox mini an der Geräte-Ebene ankam, in den Tonausgabe-Einstellungen aber weiterhin der feste Name NeXTsound Audio stand. Ursache ist, dass die USB Audio Class zwei getrennte Namens-Strings kennt: iProduct (Index 2, von Issue 24 schon dynamisch gemacht) und der eigene iInterface-String des Audio-Control-Interface (Index 4, über das dritte Argument von TUD_AUDIO_DESC_STD_AC gesetzt), aus dem macOS die Tonausgabe-Einstellungen, Audio MIDI Setup und system_profiler SPAudioDataType tatsächlich benennen. Die Behebung macht auch Index 4 von product_name abhängig, mit eigenem Rückfall-Literal. Nach dem Flashen auf dasselbe Exemplar zeigte system_profiler SPAudioDataType danach NeXT SoundBox mini statt NeXTsound Audio.³³

L. Lautsprecherdatenblatt

Das dreiseitige Dokument bezeichnet den Treiber als TEBM28C10-4/A. Auf Seite 1 und 3 steht Revision 1.9, auf Seite 2 Revision 1.8. Die Projektbezeichnung ohne Suffix stammt aus der angegebenen Chassisidentität; daraus folgt kein physischer Revisionsnachweis. Der SHA-256 des gelesenen PDFs lautet e7d4b81e45b003f2c5e0102e5969faaa5188966a5b599faac11a902dd2d5790f.

Tabelle 10 Deklarierte Werte des TEBM28C10-4/A-Datenblatts, keine Messwerte am Projektaufbau
Angabe	Wert und Bedingung	Grundlage
Nennimpedanz	4 Ω auf Seite 1.	Datenblatt
Resonanzfrequenz	Typisch 130 Hz mit ±20 % Toleranz auf Seite 1. Dies ist keine Hochpassempfehlung.	Datenblatt
Äquivalentvolumen VAS	0,15 L auf Seite 1. Dieser Treiberparameter ist nicht das Luftvolumen des Gehäuses.	Datenblatt
Leistungsangabe	10 W auf Seite 2 bei kontinuierlichem gewichteten rosa Rauschen nach IEC268-5 und Hochpass zweiter Ordnung. Eine Filtergrenzfrequenz ist nicht genannt.	Datenblatt

Nennimpedanz und Leistungsangabe allein bestimmen keine vollständige Schutzkonfiguration. Die geplante automatische Profilberechnung verwendet alle zusätzlichen verwertbaren Daten und kennzeichnet die unterstützten Modell- und Grenzaussagen. Eine Herstellerangabe ist weder eine Vermessung des eingebauten Treibers noch ein Nachweis seiner Pegel- und Auslenkungsgrenzen im konkreten Gehäuse.

M. STEP-Geometrie eines früheren Konstruktionsstands

Dieser Anhang hält die Auswertung vom 18. Oktober 2026 fest.²⁹ Sein Volumen gilt nicht für das endgültige Gehäuse, dessen Nettoluftvolumen Anhang N nennt. Die Montagebezüge beschreiben den früheren Konstruktionsstand.

Die STEP-Datei enthält vier gültige Volumenkörper und verwendet Millimeter. Die Auswertung verwendet OCP 8.0.1.1.0 und Python 3.12.13. Ihre SHA-256-Kennung lautet 6ac3b8240a66fe6c9bbe87d070da831e7b643430908557c2b8d6a0d6c30dcd20. Der benannte Eintrag NeXT Logo Plate.step / Project enthält keine Geometrie. Ein anderer generisch benannter Compound enthält zwei der Körper. Aus den Namen folgt keine vollständige Bauteil- oder Verdrängungsinventur.

Das Referenzchassis heißt im CAD TEBM28C10-4B. Das gelesene Datenblatt bezeichnet TEBM28C10-4/A. Diese Namen sind getrennte Herkunftsangaben und kein Nachweis der physischen Modellrevision.

Tabelle 11 Geometrische Montagebezüge im STEP, keine Druck- oder Montagetoleranzprüfung
Größe	Wert	Herkunft
Schallöffnung	40,0mm	Abgeleitet
Kreisförmiger Rahmensitz	57,0mm	Abgeleitet
Mittlerer Lochkreis der vier Pilotbohrungen	48,0mm	Abgeleitet
Pilotbohrungsdurchmesser	1,5mm	Abgeleitet
Referenzchassis hinter der Grille-Bezugsfläche	24,32mm	Abgeleitet
Kleinster Referenzchassis-Abstand zum Gehäusekörper	0,509mm	Abgeleitet

Die Aufnahme besitzt eine schräge Montagefläche. Die Auswertung verwendet ein rechtshändiges Baffle-Koordinatensystem mit U entlang Welt-X, V = (Y + Z) / √2 und N = (Z − Y) / √2. Numerische Koordinaten und Lochmittelpunkte stehen im strukturierten Nachweis. Der Katalog muss Rahmen, Befestigung, tiefenabhängige Körperfreiheit, Anschlüsse und weitere Einbauten zusammen berücksichtigen. Ein zulässiger Nenndurchmesser oder eine einzelne maximale Tiefe genügt nicht.

Die dargestellten Volumenwerte beziehen sich auf einen benannten geometrischen Raum. Seine Grenzen sind die inneren Seitenflächen X = ±40,25 mm, der Boden Z = 3 mm, die Rückwand Y = 29,15 mm und ein virtueller Frontabschluss an der identifizierten Grille-Bezugsfläche. Von diesem Prisma werden die modellierten Körper abgezogen. Gewählt wird die verbundene Hauptkomponente mit dem Weltpunkt (0, 15, 15) mm. Kleine abgetrennte Taschen zählen nicht dazu.

Tabelle 12 Definierter CAD-Luftbezugsraum mit virtuellem Frontabschluss
Größe	Wert	Herkunft
Hauptkomponente ohne Referenzchassis	0,1823L	Abgeleitet
Hauptkomponente mit Referenzchassis	0,1647L	Abgeleitet

Ohne virtuellen Abschluss ist der rückwärtige Luftraum im gelieferten CAD mit dem Außenraum verbunden. Die endlichen Resthohlräume sind keine Lautsprecherkammer. Der Bezugsraum ist daher kein Nachweis einer physisch dichten Box oder eines abgestimmten Bassreflexports. Die verbleibende Verdrängung von Elektronik, Steckern, Leitungen, Dichtungen und Dämpfung ist nicht als vollständige platzierte Bauteilliste belegt.

Ein zweiter geometrischer Schnitt setzt den Frontabschluss an die vorderste Ausdehnung des Referenzchassis. Er liefert 0,1723L. Diese Definitionsänderung ist eine Sensitivitätsprobe, kein physisches Unsicherheitsintervall und keine alternative Gehäuseauswahl.

Analytische Kontrollkörper prüfen die Auswertung. Eine geschlossene Würfelschale trennt einen Innenraum von 512.000 mm³ und einen Außenraum von 728.000 mm³. Eine Öffnung verbindet beide zu einer Komponente. Zwei überlappende Würfel ergeben 500 mm³ Schnittvolumen; getrennte Würfel ergeben null. Die starren Koordinatentransformationen erhalten alle Materialvolumina.

Abbildung 2 Private Geometriedarstellung des importierten STEP-Modells. Farben unterscheiden Körper. Die Darstellung ist keine akustische Messung und kein Nachweis der physischen Montage.

N. Nettoluftvolumen des endgültigen Gehäuses

Der Besitzer hat am 21. Oktober 2026 bestätigt, dass der aktuelle Konstruktionsstand endgültig und akustisch dicht ist. Er hat den Innenraum in Shapr3D als eigenen Körper modelliert, als Außenhülle abzüglich beider Gehäuseschalen, und Innenraum, Chassis und Platine einzeln als STL exportiert. Jedes Netz wurde in zusammenhängende Komponenten zerlegt, deren Volumen der Divergenzsatz liefert.³⁸

Tabelle 13 Volumina des endgültigen Gehäuses
Größe	Wert	Herkunft
Modellierter Innenraum	0,196018L	Abgeleitet
Verdrängung des Chassis TEBM28C10-4/A	0,017153L	Abgeleitet
Verdrängung der RP2350-Platine mit Bauteilen	0,000533L	Abgeleitet
Nettoluftvolumen	0,178332L	Abgeleitet

Das Chassisnetz besteht aus einem Hauptkörper und vier entarteten Komponenten ohne Volumen, das Platinennetz aus 84 Komponenten für Platine, Stecker und Bauteile. Die Volumina sind für ein dichtes, einheitlich orientiertes Netz exakt, ein zweiter Geometriekern hat sie aber nicht gegengeprüft. Der Innenraum hängt an der booleschen Operation in Shapr3D. Verstrebungen, Kleber, Dämpfung, Leitungen und andere nicht modellierte Einbauten sind nicht abgezogen. Die STL-Dateien lagen nur während der Auswertung vor, deshalb fehlen ihre SHA-256-Prüfsummen; der Datensatz hält stattdessen Dreieckszahlen, Volumina und Ausdehnungen fest. Die Closed-Box-Abstimmung der App rechnet mit diesem Nettoluftvolumen.³⁷