Musicians lose their hearing partly because the protection that would save it makes their instrument sound wrong, so they take the earplugs out. MUTE attacks that adoption problem directly: it measures how a given pair of earplugs changes your hearing, then lets you hear your own recordings filtered to match, as auditory training to make the trade-off feel acceptable. It was a University of Washington master's capstone, built with the NOISE Lab at UT Dallas, and it was a team effort. I led the full-stack engineering; my teammate Annie Staker designed the audio-processing algorithms at the core of it; and Dr. Allison Woodford, the audiologist who sponsored the project, grounded it clinically. There is a fuller roster at the end.

It is also, underneath the research framing, a production-shaped backend, and that backend is the part I owned. This is the account of the parts I would point to in a code review.

A background job queue without Redis

The signature engineering decision is that the asynchronous audio-processing pipeline runs on PostgreSQL alone, with no Redis or Celery. A worker process polls for pending jobs and claims them with SELECT ... FOR UPDATE SKIP LOCKED, so several workers can run at once and never grab the same job. Jobs move through a small lifecycle (pending, running, complete, failed) with a retry count and a cap, and on startup the worker resets any job that has been stuck running for too long, which is the crash-recovery path for a worker that died mid-render.

The trade-off was deliberate and I would make it again at this scale: one fewer service to run and pay for, job state that lives transactionally alongside the rest of the data, in exchange for polling latency and lower throughput than a dedicated broker. For a research deployment that processes audio for a study population, that is the right side of the trade. The honest caveat is that it is not built for high-volume throughput, and I would not pretend otherwise.

From two hearing tests to a filter

The domain core is the path from measurement to sound. A user takes two pure-tone hearing tests in the browser, generated with the Web Audio API across seven audiometric frequencies from 500 Hz to 8 kHz: one baseline, one wearing their earplugs. The system takes the per-frequency difference between the two to derive an attenuation curve, with a heuristic that detects when the two tests were taken in the wrong order and flags it rather than silently inverting the result.

That curve becomes a filter. The DSP engine loads the audio, takes its real FFT, interpolates the attenuation curve across every frequency bin, converts decibels to a linear scale, scales the magnitudes while preserving phase, and inverts the transform back to time. The default interpolation is a natural cubic spline, clamped flat outside the measured range so spline overshoot does not introduce artifacts at the edges, a fix that is visible in the code because the naive version produced exactly that artifact. There are five interpolation methods in total; cubic spline is the one the production path uses. The DSP is hand-written on top of NumPy and SciPy, not an off-the-shelf equalizer, because the whole point of the project is to experiment with which curve produces the most natural earplug simulation. The audio-processing design here is Annie Staker's work. She is the audio expert on the team, and the modeling choices behind the attenuation curve and the interpolation methods come from her; my part was the engineering around those algorithms, turning them into a background service that runs them reliably.

Security and consent, because the data is sensitive

Hearing measurements are health data attached to identifiable people, so the auth and privacy layers got real attention. Passwords are hashed with Argon2id tuned to a 64 MB memory cost. Access is a short-lived JWT; refresh tokens are opaque random strings of which only the SHA-256 hash is ever stored, rotated on every refresh and revoked en masse on a password change. Access control has three roles, and ownership is checked per resource, including the indirect case where a processing job has no direct user column and ownership has to be resolved by joining through the earplug registration that produced it.

Consent is captured at registration and on every change, written to an append-only audit log with a timestamp. Right-to-erasure is implemented as a hard delete that removes every related row in foreign-key-safe order. One detail I am happy with: the IP-address columns were deliberately dropped in a migration, because the system did not need them and not collecting data is the strongest privacy guarantee there is.

What it is not

It is worth being precise, because the easy description overclaims. There is no machine learning anywhere in MUTE. The personalization is deterministic signal processing, an FFT and a measured attenuation curve, not a trained model, and I would not call it AI. It is a web application, not a native mobile app; that was an explicit scope decision to fit a single quarter, with the API designed so a mobile client stays possible later. Email is integrated but defaults to a console provider, and email verification is feature-flagged off by default, so I would not describe it as a live email system without that qualifier.

Scale

Ninety-nine endpoints across eighteen routers, a fifteen-table schema, and 274 automated tests split across unit, integration, and end-to-end levels, including tests that run real audio through the filter. It is deployed as three services on Railway: the API, the DSP worker, and the frontend, plus managed PostgreSQL and object storage. The number I find most telling is the test count, because for a capstone the easy path is to build the demo and stop, and the tests are the evidence that this was built to be maintained.

The team

MUTE was a three-person project, and the parts that make it work were genuinely shared.

Annie Staker, audio-processing algorithms. Annie is a Master's of Data Science graduate with a B.S. in Applied Mathematics from the University of Utah. Before grad school she spent three years in biotech designing COVID-19 detection algorithms, and she now develops deep learning models for 3D chromatin organization in the Department of Genome Sciences. She is the expert behind the audio-processing algorithms that power MUTE. LinkedIn

Dr. Allison Woodford, AuD, researcher, audiologist, and sponsor. Allison is a doctor of audiology and a PhD candidate at the University of Texas at Dallas. A clinician-scientist with a background in collegiate vocal performance, she bridges the clinical, scientific, and performing-arts worlds in research on the auditory health of musicians and music-industry professionals, and she sponsored MUTE and grounded it clinically. LinkedIn

Richard Pallangyo, full-stack engineering. I led the engineering effort, architecting the FastAPI backend, the PostgreSQL data model, the async DSP pipeline, and the Next.js frontend. LinkedIn