# Crowd-Sync — Werte lesen und Fehler eingrenzen

Das Debug-Panel im Player öffnest du mit **fünfmal Tippen auf den Titel**. Auf der Sendeseite stehen die Werte direkt sichtbar unter den Pegeln.

---

## Player (Zuhörer)

| Feld | Soll | Wenn es abweicht |
|---|---|---|
| **timing** | `clock` | `free` = die Uhr ist nicht eingerastet, die Wiedergabe läuft ohne Gleichtakt. Muss nach wenigen Sekunden umspringen. |
| **state** | `streaming` | `waiting` = kein Sender aktiv · `reconnecting` = Verbindung bricht |
| **frames/s** | **50** bei 20-ms-Frames | 100 bei 10 ms, 25 bei 40 ms. Sackt der Wert ab, gehen unterwegs Pakete verloren. |
| **glitches/s** | **0** | Jeder Wert darüber ist ein hörbarer Aussetzer. |
| **resyncs** | **0**, höchstens einer beim Start | Steigt laufend = Uhr oder Netz instabil. |
| **drift** | **±3 ms um null**, ohne Trend | Der Wert ist geglättet. Wandert er dauerhaft in eine Richtung, laufen die Raten auseinander. Rot ab 10 ms. |
| **late drops** | **0** | Steigt stetig = der Vorlauf ist für diese Strecke zu knapp → Buffer-Regler höher. |
| **actual lead** | ungefähr der Reglerwert | Schwankt naturgemäß um ein paar ms — das ist die Blockauflösung der Audio-Uhr, kein Fehler. **Rot = der Vorlauf ist kürzer als ein Frame** (siehe unten). |
| **frame** | Frame-Länge des Senders | 10 / 20 / 40 ms, je nach Einstellung auf der Broadcast-Seite |
| **rate trim** | **unter ±0,1 %** | Die laufende Feinkorrektur. Klebt sie dauerhaft an ±0,3 %, kommt die Regelung nicht hinterher — dann laufen die Uhren wirklich auseinander. |
| **RTT** | **< 5 ms** im LAN | Über das Internet eher 20–40 ms. |
| **clock off** | beliebiger Wert, **stabil** | Springt er um mehrere ms, ist die Uhrschätzung unruhig. |
| **ctx rate** | **48000 Hz** | Alles andere heißt, der Empfänger resampelt zusätzlich. |
| **src rate** | **≈ 48000 Hz** | ≈ 44100 = die Sendekette läuft auf 44,1 kHz → Formate angleichen, siehe [AUDIO-SETUP.md](AUDIO-SETUP.md) Schritt 4. |
| **reconnects** | 0 | |

Regler darunter: **Buffer 35**, **Auto-Haken aus**, **± auf 0** — bis du pro Gerät nachjustierst.

## Sender (Broadcast-Seite)

| Feld | Soll |
|---|---|
| **state** | `broadcasting` |
| **capture** | `worklet`. Steht dort `main thread`, glitcht es für **alle** Hörer, sobald der Tab in den Hintergrund kommt. |
| **rate** | 48000 Hz |
| **frames/s** | 50 (bei 20 ms) |
| **source gaps** | **0**. Klettert der Wert, liegt es am sendenden PC — nicht am Netz und nicht am Empfänger. |
| **listeners** | Anzahl der Hörer |
| **dropped (srv)** | 0 |

---

## Eingrenzen in drei Schritten

**1. Liegt es am Sender?** `source gaps` steigt → ja. Ursachen: Tab im Hintergrund (`capture` muss `worklet` sein), CPU-Last, oder ein virtuelles Kabel mit falschem Format. Alles Weitere ist dann Folge, nicht Ursache.

**2. Liegt es an den Sampleraten?** `src rate` deutlich neben 48000 → die Sendekette konvertiert. Bei VB-Cable müssen **Wiedergabe- und Aufnahmeseite dasselbe Format** haben; ungleiche Werte sind die häufigste Knackser-Ursache überhaupt.

**3. Liegt es am Netz?** `late drops` steigt, während `source gaps` auf 0 bleibt → das Netz schafft den eingestellten Vorlauf nicht. Buffer-Regler hochziehen, bis es hält.

---

## Warum der Vorlauf nicht automatisch wächst

Der Auto-Haken ist bewusst **aus**. Er erhöht bei jedem Aussetzer den Puffer und verankert die Wiedergabe neu auf die lokale Zeit — das rettet ein einzelnes Gerät und wirft es dafür dauerhaft aus dem Gleichtakt mit allen anderen. Genau das Gerät mit dem schlechtesten Empfang läuft dann am weitesten hinterher.

Für Gleichtakt gilt deshalb: fester Vorlauf, und wer ihn nicht hält, setzt kurz aus und steigt an der richtigen Stelle wieder ein. Der Regler bleibt als Handbremse für schwierige Umgebungen — bewusst gesetzt, nicht automatisch.

## Vorlauf richtig wählen

**Grundregel: Der Vorlauf muss größer sein als eine Frame-Länge.** Sonst kann der Puffer nicht einmal ein einziges verspätetes Paket auffangen — und das hörst du als regelmäßiges Knacken, völlig unabhängig davon, wie gut Netz und Rechner sind. Zeigt das Feld **actual lead** rot, ist genau das der Fall.

| Frame-Größe (Sender) | Vorlauf mindestens | angenehm |
|---|---|---|
| 10 ms | 20 ms | 30–40 ms |
| **20 ms** (empfohlen) | 30 ms | **35–50 ms** |
| 40 ms | 50 ms | 60–80 ms |

Dazu die Umgebung:

| Umgebung | Aufschlag |
|---|---|
| Kabel / gutes 5-GHz-WLAN | keiner, Minimum reicht |
| WLAN mit vielen Geräten, großer Raum | +30–60 ms |
| Über das Internet (z. B. die Demo) | **150–300 ms gesamt** |

Größere Frames sind sparsamer im Netz (weniger Pakete, weniger Overhead), kosten aber genau diesen höheren Mindestvorlauf. 20 ms ist der Kompromiss, der fast immer passt. 10 ms lohnt nur bei Kabel oder erstklassigem WLAN.

Über das Internet sind 35 ms grundsätzlich zu wenig — dort zählen die late drops zwangsläufig hoch.

## Warum es nicht mehr an den Nahtstellen knackt

Audio wird in Blöcken abgespielt, die lückenlos aneinandergrenzen müssen. Verschiebt man den Abspielzeitpunkt eines Blocks um X, entsteht an der Naht eine Lücke oder Überlappung von exakt X — schon 0,2 ms (rund 10 Samples) sind bei lautem Material ein hörbarer Klick.

Deshalb wird die laufende Feinkorrektur **nicht** über verschobene Startzeiten gemacht, sondern über die Abspielrate: Ein Block wird um Bruchteile eines Prozents gedehnt oder gestaucht. Das verschiebt die Position ohne jede Diskontinuität. Gemessen über 756 Blöcke: Nahtabweichung exakt 0. Die Tonhöhenänderung liegt bei maximal 0,3 % (etwa 5 Cent) und ist nicht wahrnehmbar.

Nur bei groben Abweichungen (über 60 ms) wird hart neu eingerastet — dann bewusst mit kurzer Stille statt mit einem Sprung mitten im Ton.

## Geräte aufeinander abstimmen

Bleibt ein Gerät hörbar versetzt, obwohl **drift** bei null steht, ist das seine Ausgabeverzögerung — Bluetooth-Kopfhörer liegen leicht 100–200 ms hinten. Dafür ist die **±-Feinjustierung** da: Sie wird pro Gerät gespeichert und einmal eingestellt.

Am schnellsten geht das im Vergleich: zwei Geräte nebeneinander, auf einem nachjustieren, bis die beiden Klicks zu einem verschmelzen.
