feat: add validated audio laboratory gates - #5
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8f70e1b55b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if receipt.get("physical_state_sha256") != physical_sha: | ||
| invalidated[gate] = "physical-state-changed" | ||
| continue | ||
| resolved.add(gate) |
There was a problem hiding this comment.
When an XRun receipt was recorded for another rate or quantum—for example 48 kHz/1024 frames—this unconditional resolution still satisfies piano-software-live, which requires testing its 128-frame candidate. The stored graph_fingerprint, rate, and quantum are only format-checked and never compared with the current graph; the same issue lets a Qobuz proof survive a track or graph change. Consequently, audio-plan can report readiness based on observations from an unrelated configuration, so these gates need to be invalidated unless their recorded graph context matches the context being planned.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Behoben in d596b2fadc14e24a88bac34653be990d3632093b: Der Planer bildet nun einen kanonischen Fingerprint des konkret geplanten Graphen aus Standardziel, Standardquelle, Samplerate und Quantum. Loopback- und XRun-Belege müssen exakt diesem Fingerprint entsprechen. Qobuz-Belege benötigen zusätzlich aktuellen Track-Fingerprint und Track-Samplerate; ohne aktuellen Trackkontext bleibt das Gate blockiert. Regressionstests: test_xrun_gate_rejects_unrelated_graph und test_qobuz_gate_requires_current_track_and_graph.
| "result": "pass" if passed else "fail", | ||
| "measured_at": measured_at(), | ||
| "physical_state_sha256": physical_sha(physical_state), | ||
| "source_wav": file_binding(wav), |
There was a problem hiding this comment.
If the WAV is modified or replaced after LEVEL.analyze(wav) returns but before this call, the resulting evidence contains measurements from the old bytes and a SHA-256 binding for the new bytes. The loopback path has the same analyze-then-bind ordering for both inputs, so concurrent recording, file replacement, or another writer can create apparently hash-bound evidence that cannot reproduce its analysis. Analyze a stable opened copy, or hash before and after analysis and reject changes.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Behoben in d596b2fadc14e24a88bac34653be990d3632093b: Vor jeder Analyse wird die Quelle über einen O_NOFOLLOW-gebundenen Descriptor in eine private 0600-Momentaufnahme kopiert und dabei gehasht. Analyse und SHA-256 beziehen sich damit auf exakt dieselben Bytes. Dev/Inode/Größe/mtime/ctime werden vor und nach der Kopie verglichen; Änderungen brechen fail-closed ab. Regressionstest: test_voice_analysis_and_hash_use_same_snapshot.
| if latency < 0 or latency > 500: | ||
| raise ValueError("round-trip latency is outside the accepted measurement range") | ||
| _positive_int(analysis.get("sample_rate_hz"), "sample_rate_hz") | ||
| _nonnegative_int(analysis.get("delay_samples"), "delay_samples") |
There was a problem hiding this comment.
When evidence is supplied from an external observer or edited before recording, the validator accepts round_trip_latency_ms, sample_rate_hz, and delay_samples independently. For example, a receipt can claim a passing 1 ms latency while reporting 24,000 samples at 48 kHz, and it will still resolve the gate. Verify that the reported latency equals delay_samples / sample_rate_hz * 1000 within the analyzer's rounding tolerance so contradictory measurement results cannot pass validation.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Behoben in d596b2fadc14e24a88bac34653be990d3632093b: Der Validator berechnet round(delay_samples / sample_rate_hz * 1000, 3) selbst und verwirft widersprüchliche Millisekundenwerte fail-closed. Regressionstest: test_rejects_contradictory_loopback_latency.
|
@codex review Bitte den vollständigen aktuellen Head |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d596b2fadc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| `create-audio-evidence loopback-latency REFERENZ.wav AUFNAHME.wav | ||
| --quantum-frames 128` verwendet den bestehenden Impulsanalysator. Ein positiver |
There was a problem hiding this comment.
The documented loopback command cannot run as written. I checked create-audio-evidence loopback-latency --help, which lists --graph-fingerprint GRAPH_FINGERPRINT as required by measurement_evidence.py, and executing this exact example exits in argument parsing with “the following arguments are required: --graph-fingerprint”. Include the planned fingerprint and explain how to obtain it so users can actually create loopback evidence.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Behoben in dbb7d1286da671f3a4650c590ab6fb8387ebbf09: Die Dokumentation liest planned_graph_fingerprint explizit mit audio-plan piano-software-live aus und übergibt ihn zusammen mit --quantum-frames 128 an create-audio-evidence loopback-latency. Der vollständige Prüflauf kontrolliert, dass beide Optionen in der echten CLI-Hilfe vorhanden sind und die dokumentierte Shell-Syntax exakt enthalten ist.
| if evidence.get("xrun_delta") != 0: | ||
| raise ValueError("XRun observation contains new XRuns") |
There was a problem hiding this comment.
When externally produced XRun evidence encodes xrun_delta as false, this comparison accepts it because Python considers False == 0; 0.0 is accepted for the same reason. Since XRun evidence has no in-repo creator and is recorded from external JSON, malformed non-integer evidence can therefore resolve xrun-stability-test despite the claimed strict typing. Validate this field as a nonnegative integer before requiring it to equal zero.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Behoben in dbb7d1286da671f3a4650c590ab6fb8387ebbf09: xrun_delta wird nun zuerst mit _nonnegative_int typgeprüft und erst danach auf exakt 0 geprüft. False, True, 0.0 und 1.0 werden abgewiesen; nur Integer 0 besteht. Regressionstest: test_rejects_boolean_and_float_xrun_delta.
|
@codex review Bitte den vollständigen aktuellen Head |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dbb7d1286d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| confidence = float(analysis["peak_detection_confidence"]) | ||
| snr = float(analysis["peak_snr_db"]) | ||
| latency = float(analysis["round_trip_latency_ms"]) | ||
| passed = confidence >= 0.8 and snr >= 20.0 and 0.0 <= latency <= 500.0 |
There was a problem hiding this comment.
When the same impulse WAV is supplied as both reference and recorded—or the recording is trimmed so both impulses have the same sample offset—the analyzer reports zero delay with high confidence, and this condition marks it as passing; validate_loopback_latency likewise accepts zero. The resulting receipt can resolve the loopback gate and make piano-software-live ready despite measuring no physical round trip. Require a strictly positive delay and reject identical source hashes.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Behoben in d58d629ec5a00f9594221bf63690ed51c5be4e6d: Loopback-Belege verlangen nun strikt positive delay_samples und round_trip_latency_ms; Referenz- und Aufnahme-SHA-256 müssen verschieden sein. Auch der Generator setzt result: pass nur bei positiver Verzögerung und unterschiedlichen Quellbytes. Regressionstests: test_rejects_zero_delay_or_identical_loopback_sources und test_identical_loopback_sources_do_not_pass. Der vollständige Prüflauf umfasst 63 Tests.
|
@codex review Bitte den vollständigen aktuellen Head |
|
Codex Review: Didn't find any major issues. Breezy! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
1 participant
Ziel
Die bisher statischen Labor-Gates der Audio-Profile durch private, validierte und hashgebundene Messbelege tatsächlich erfüllbar machen, ohne Wiedergabe, Routing oder produktive Audioeinstellungen zu verändern.
Inhalt
Prüfung
just check, Ruff, Shellcheck, Compileall und Audio-Sicherheitsprüfung PASS6487de5e3d862b48ad75c0a368bcdf632b5bad7487360ece044993cd08b7b6b236fe8acb09940805c274202ee6f36b09ca8b5e5ce12552d105e0ef930c5a6757Reviews
Alle Funde der ersten drei Codex-Reviews wurden revisionsgebunden mit Regressionstests behoben. Ein vierter vollständiger Review auf
d58d629ec5a00f9594221bf63690ed51c5be4e6dist angefordert.Abgrenzung
Keine automatische Wiedergabe, kein Profil-Apply, keine Änderung an PipeWire, WirePlumber, Standardgeräten, Sample-Rate, Quantum, Gain, 48 V, Receiver, Bluetooth oder Qobuz. Reale Messbelege werden erst nach den jeweiligen physischen beziehungsweise aktiven Laborarbeiten gespeichert.