Start from one release path

The component owns four pieces of mutable audio state: an AudioContext, an OscillatorNode, a GainNode, and the animation frame used to update the UI. Instead of scattering cleanup across handlers and effects, the implementation uses one release function.

That function cancels the animation frame, clears references, marks the cycle as inactive, and handles the audio nodes. A user-initiated stop takes a short gain ramp before stopping the oscillator. An unmount or completed cycle can release immediately. Both paths disconnect the nodes and close the context when it is still open.

The invariant is simple: after release, there should be no active oscillator, no animation loop, and no open audio context owned by the component.

A visibility change is a real stop condition

The browser exposes document.visibilityState through the visibilitychange event. When the document becomes hidden and a cycle is running, the component calls the same stop behavior used by the visible stop button.

A user who switches apps should not be surprised by audio continuing from a background tab. The progress display and sound should not drift apart, either. The event listener is installed in an effect and removed in its cleanup; the effect also releases audio so navigation cannot leave a context behind.

Keep the signal bounded and explain what it is

The oscillator uses a sine wave. The frequency follows a triangle sweep between 150 and 190 Hz, repeating every four seconds, while the full cycle lasts 90 seconds. A pure frequency helper lets the progress label and oscillator update use the same elapsed-time model.

That sweep is a product choice, not a universal phone-speaker setting. Web Audio can generate and route a signal; it cannot prove that the signal removes water from an unmeasured device. The gain envelope ramps up, holds the configured level, and ramps down at the end. A fade makes the interaction gentler, not a physically damaged device safe.

User gestures and browser permissions

The cycle begins from a button press. The component creates and resumes the AudioContext in that user gesture because browsers commonly restrict automatic audio playback.

There is no microphone request and no file upload. The page sends generated audio to the browser’s selected output. If audio construction or resume fails, the UI should show an error instead of leaving a progress ring that falsely suggests playback.

The UI should not infer physical success

A progress ring knows elapsed playback time. It does not know whether a droplet moved, whether the grille is blocked, or whether a speaker is damaged. Completion means the cycle finished; the user should then test familiar audio. It does not mean the phone is repaired.

The page also asks users to remove the case, disconnect cables and wireless audio, wipe visible moisture from the outside, and point the speaker downward. Heat, charging warnings, persistent crackling, silence, and other hardware symptoms are reasons to stop and follow the device maker’s guidance. The Speaker Cleaner homepage is the broader entry point; the Water Eject page contains the focused tool and checklist.

What I would test next

1. Start and stop repeatedly without increasing active contexts.
2. Switch tabs during the cycle and confirm playback stops.
3. Navigate away and back, checking that no stale animation callback updates an old component.
4. Exercise failures when audio construction or resume does not succeed.
5. Record browser and device setup rather than turning a few observations into a universal success rate.

The code can prove that it created, updated, stopped, and cleaned up a signal. It cannot prove a physical result on every phone. Keeping those two test questions separate is the important part of this design.