Soundcheck: Source to Sound

Hear a real recording change for 20 seconds, then trace both sound files to the exact GitLab commit and passing CI jobs.

Comment

Inspiration

An audio engineer needs to hear a filter change before deciding to release it. A passing pipeline answers whether the checks passed. The listening result still needs to be connected to the code that produced it.

Soundcheck makes that connection visible: listen to A and B, inspect the returned files, and follow them back to a GitLab commit and its CI evidence.

What it does

The live judge page plays 20 seconds of a real public-domain recording and a digital FIR smoothing candidate. It verifies five published pieces before joining each continuous take. You can replay either version, inspect the release and download the original files. A separate route renders a fresh short A/B through the deployed backend.

The GitLab workflow brings a proposed source change into the same review loop. In the recorded Duo Agent Platform session, the agent read an issue and repository files, waited for human approval, and created a branch, code-and-test commit and draft MR. A separate session refused a request to bypass CI. A later flow posted a bounded MR review note.

This is an Assisted workflow. People performed the observed merges, deployment and release publication. The project spans the nine lifecycle stages below through a combination of Duo, CI and operator actions. It does not demonstrate nine autonomous agent stages.

How I built it

The React/TypeScript client verifies audio bytes before playback. Mediabunny decodes short browser imports. A Python digital renderer runs on Google Cloud Run; Firestore stores release records and Cloud Storage retains content-addressed artifacts. The Expo/React Native app uses the same deployed evidence API.

GitLab Duo Agent Platform provides the source-change flow, human approval component, refusal path and bounded review flow. GitLab CI checks the compiler, audio engine, web/native clients, evidence API, security and package. The deployment gate checks the exact source and package, then verifies release bytes after a new Cloud Run revision replaces the old one. Deployment code is included in the public repository.

AI coding assistants helped with implementation, tests and review. Their output still needed source inspection, executed checks and actual recordings. In the observed Duo-authored MR, a person corrected a test before merging it.

Challenges I ran into

  • A loading audio preview moved an upload consent checkbox during a click. Consent now waits for preparation, with a regression that holds the real encoded-byte read.
  • Device automation reported success while showing the short sample. I corrected the guided navigation and inspected the encoded recording for both 20-second endpoints.
  • A healthy deployment did not establish durable audio. The live check now compares the stored release bytes before and after redeployment.
  • Digital evidence and speaker evidence needed separate claims. The film includes real phone-recorded speaker playback, labelled as edited excerpts rather than a calibrated room comparison.

Accomplishments I'm proud of

The product offers a complete listening-to-source path without a judge login. Its published release connects the recording, filter graph, audio hashes, source and 14 successful required CI jobs. The film shows the recorded human approval, refusal, MR, CI and release evidence alongside the audible result.

The Android build-3 APK and receipt are public Release downloads. A real Pixel 8 recording shows both A and B reaching 20.00/20.00 seconds. That device recording is silent and proves visible playback progression. The film's separate speaker excerpts contain the actual phone audio.

Lifecycle coverage and who acted

Stage Demonstrated action Actor
Plan Read issue #3 and propose a scoped source change Duo, then human approval
Create Author branch, code-and-test commit and draft MR !26 Duo; later human correction and merge
Verify Post bounded MR review; execute exact-source tests Duo review flow and GitLab CI
Package Build a source-marked container GitLab CI
Secure Run secret detection and report guards GitLab security and CI
Release Publish source-linked audio and native downloads Operator and deterministic publisher
Configure Apply a verified package to dedicated Cloud Run infrastructure Operator-invoked deployment gate
Monitor Read deployed source and diagnostic host state Deployed API and verification tools
Govern Refuse a CI bypass; retain human merge/release decisions Duo refusal and people

Environmental observation

Serving stored, verified audio avoids rerendering it for every delivery. A six-window Cloud Run comparison delivered identical artifact bytes for the complete 4.157-second sample under matched request counts. It observed 91.28% less allocated vCPU time per verified delivery than an engineered render-per-delivery reference. This is a bounded compute-allocation observation, not measured energy, carbon, an SCI score or a product-wide saving. Configuration parity was operator-recorded; a service-configuration snapshot was not archived.

What I learned

Enough uninterrupted playback matters more than another proof badge. Twenty seconds lets someone hear the result, while the release links let them check its origin.

Agent authorship, human approval, passing CI and deployment are separate events. Naming the actor at each step made both the product and its limits clearer.

A successful device-test status is not enough. The recorded UI must show the intended sample and actual progress. Speaker playback also needs its own evidence; a screen recording cannot establish room acoustics.

What's next

Complete the physical iPhone 20-second test and make TestFlight available after Apple's review. Separately, validate calibrated physical measurements and the unfinished CI-repair execution boundary before enabling either path. Neither is presented as completed here.

Try it

  1. Open the live audition, select "Verify and load A/B," then play A and B.
  2. Inspect the release and follow its source, WAV and CI links.
  3. Read MR !26 and the public flow evidence. Hosted session pages require project access; public screenshots and the MR remain available.

Source and evidence scope

  • Filmed/live website: 024725b88df864e083874cdf5bd732e8f45416bb.
  • Repository main at preparation: 7517d3b28efff8657740b9e7608595ea25470895, with its own 14-job main pipeline.
  • Native build 3: 310dde8253e236ba5ca9fa02eb8f0cdd04137268. Pixel footage used backend c8c2b98db6445ec4edfc1998f56d8fef0b211edb; the filmed iPhone is an earlier one-second UI on a384616.
  • iOS 0.1.0 (3) is processed VALID and waiting for external beta review. No public TestFlight link is available as of October 20, 22:08 UTC.
  • Digital audio does not establish acoustic benefit. The Mac diagnostic host reports offline, with physical control disabled. Phone A/B excerpts demonstrate playback, not a calibrated comparison.
  • The repair flow is disabled. Current main permits Developer pushes; a single reviewer who is also the author is not an enforced second-person merge gate.
  • Demo video: https://www.youtube.com/watch?v=pgcmnXmLTd8. Prepared film duration: 2:46.

Recording credit: Library of Congress Citizen DJ, "Joe Turner blues" medley excerpt. Collection reuse terms.

Built With

Share this project:

Updates

Submission history