rot in 2 von 5 Einzelläufen bei #351 auf melektaus-atx, HEAD war 2 von 2 grün
Abweichend ist immer nur position.ticks gegen heardTicks, und zwar um ein ganzes Vielfaches eines Render-Quantums (128 Samples = 2,9 ms = 3,5 Ticks bei 150 BPM). Die Toleranz ist 1 Tick.
Ursache
Der Check liest Position und Audio-Uhr in einem Ausdruck nacheinander:
position() liest currentTime selbst, clock() danach noch einmal. In Chrome läuft AudioContext.currentTime auch innerhalb einer Aufgabe weiter, sobald der Audio-Thread einen Block fertig hat. Liegt ein Block zwischen den beiden Lesungen, passt die nachgerechnete Position nicht mehr. Der Scheduler selbst rechnet richtig.
Plan
Die Uhr vor und nach position() lesen und prüfen, dass die Position zwischen den beiden daraus gerechneten Stellen liegt (± 1 Tick, auch über die Naht der Schleife).
Kein Umbau am Produkt.
## Befund
Der Check in e2e 34 „the scheduler plans a looped bar on the audio clock …“ wackelt:
- rot in CI-Task 580 (`490fcba`, #359)
- rot in 2 von 5 Einzelläufen bei #351 auf `melektaus-atx`, HEAD war 2 von 2 grün
Abweichend ist immer nur `position.ticks` gegen `heardTicks`, und zwar um ein ganzes Vielfaches eines Render-Quantums (128 Samples = 2,9 ms = 3,5 Ticks bei 150 BPM). Die Toleranz ist 1 Tick.
## Ursache
Der Check liest Position und Audio-Uhr in einem Ausdruck nacheinander:
```js
({ position: __gm.music.position(), clock: __gm.sound.clock(), latency: … })
```
`position()` liest `currentTime` selbst, `clock()` danach noch einmal. In Chrome läuft `AudioContext.currentTime` auch innerhalb einer Aufgabe weiter, sobald der Audio-Thread einen Block fertig hat. Liegt ein Block zwischen den beiden Lesungen, passt die nachgerechnete Position nicht mehr. Der Scheduler selbst rechnet richtig.
## Plan
- Die Uhr vor **und** nach `position()` lesen und prüfen, dass die Position zwischen den beiden daraus gerechneten Stellen liegt (± 1 Tick, auch über die Naht der Schleife).
- Kein Umbau am Produkt.
admin
added this to the Development project 2026-10-09 09:49:20 +02:00
admin
moved this to Next in Development on 2026-10-09 09:49:22 +02:00
admin
moved this to Done in Development on 2026-10-09 09:49:35 +02:00
Behoben mit 87ec62a, „Keep the scheduler check in e2e 34 from flaking on a clock tick (#366)“.
Was sich ändert
Der Check liest die Audio-Uhr jetzt vor und nachposition(). Die Position muss zwischen den beiden daraus gerechneten Stellen liegen, mit 1 Tick Spielraum, auch über die Naht der Schleife.
Am Produkt ist nichts geändert, der Scheduler rechnet richtig.
Tests
e2e 34 (melektaus-atx) → ALL PASSED – 93 Checks, 3 von 3 Läufen
Gegenprobe → Position um 10 Ticks verschoben: genau dieser Check rot
node --check, Prettier, ESLint auf e2e 34 → sauber
Nicht geprüft
3 grüne Läufe beweisen es nicht ganz, vorher war der Check in 2 von 5 Läufen rot. Der Fix stützt sich vor allem auf die Ursache. Wird der Check wieder rot, ist das ein neuer Befund.
Das Gate lief nicht, weil sich nur die e2e-Datei geändert hat.
Behoben mit `87ec62a`, „Keep the scheduler check in e2e 34 from flaking on a clock tick (#366)“.
## Was sich ändert
- Der Check liest die Audio-Uhr jetzt **vor und nach** `position()`. Die Position muss zwischen den beiden daraus gerechneten Stellen liegen, mit 1 Tick Spielraum, auch über die Naht der Schleife.
- Am Produkt ist nichts geändert, der Scheduler rechnet richtig.
## Tests
```
e2e 34 (melektaus-atx) → ALL PASSED – 93 Checks, 3 von 3 Läufen
Gegenprobe → Position um 10 Ticks verschoben: genau dieser Check rot
node --check, Prettier, ESLint auf e2e 34 → sauber
```
## Nicht geprüft
- 3 grüne Läufe beweisen es nicht ganz, vorher war der Check in 2 von 5 Läufen rot. Der Fix stützt sich vor allem auf die Ursache. Wird der Check wieder rot, ist das ein neuer Befund.
- Das Gate lief nicht, weil sich nur die e2e-Datei geändert hat.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Befund
Der Check in e2e 34 „the scheduler plans a looped bar on the audio clock …“ wackelt:
490fcba, #359)melektaus-atx, HEAD war 2 von 2 grünAbweichend ist immer nur
position.ticksgegenheardTicks, und zwar um ein ganzes Vielfaches eines Render-Quantums (128 Samples = 2,9 ms = 3,5 Ticks bei 150 BPM). Die Toleranz ist 1 Tick.Ursache
Der Check liest Position und Audio-Uhr in einem Ausdruck nacheinander:
position()liestcurrentTimeselbst,clock()danach noch einmal. In Chrome läuftAudioContext.currentTimeauch innerhalb einer Aufgabe weiter, sobald der Audio-Thread einen Block fertig hat. Liegt ein Block zwischen den beiden Lesungen, passt die nachgerechnete Position nicht mehr. Der Scheduler selbst rechnet richtig.Plan
position()lesen und prüfen, dass die Position zwischen den beiden daraus gerechneten Stellen liegt (± 1 Tick, auch über die Naht der Schleife).Behoben mit
87ec62a, „Keep the scheduler check in e2e 34 from flaking on a clock tick (#366)“.Was sich ändert
position(). Die Position muss zwischen den beiden daraus gerechneten Stellen liegen, mit 1 Tick Spielraum, auch über die Naht der Schleife.Tests
Nicht geprüft