Designing a Clear Browser Audio Capture Flow for Music Search

A browser audio interface has to communicate several different states: permission has not been requested, recording is active, audio is ready, a request is running, and a result is available. Treating all of these as one “Search” button makes failures difficult for users to understand.

A music finder such as Hum to Search offers a useful product context: its public interface separates humming from identifying an original recording and includes an audio upload control. The implementation below is a standalone design example, not a description of that website's private code or recognition backend.

Separate capture from submission

Model the interaction with explicit states, for example idle, requesting-permission, recording, ready, submitting, completed and error. Stopping a recording should produce a reviewable input before any optional paid or credit-consuming request is sent.

The recording step and the recognition request can fail independently. A permission failure should explain how to enable the microphone. A server failure should explain whether the input remains available for retry. A no-match result should be presented as an outcome of a completed search, rather than being confused with a transport error.

Release the microphone explicitly

Here is a minimal JavaScript helper for a microphone session. It deliberately leaves recording formats and server submission to the surrounding application:

async function openMicrophone() {
  if (!navigator.mediaDevices?.getUserMedia) {
    throw new Error('Microphone capture is unavailable here.');
  }
  const stream = await navigator.mediaDevices.getUserMedia({ audio: true });
  return {
    stream,
    close() {
      stream.getTracks().forEach((track) => track.stop());
    },
  };
}

Call close after the capture has finished and during cancellation or component cleanup. The application should also handle a request that finishes after the user has already left the recording screen: stop any late-arriving stream instead of keeping the microphone open.

Keep the selected input mode visible

A hummed melody and an original recording are different kinds of input. Preserve the selected mode next to the recording and again near the submit control. If a user uploads a file, make it clear whether that replaces an earlier recording. Do not silently submit a stale clip after the user switches modes.

Give retries a defined meaning

Disable repeated submission while a request is active. When the server supports request identifiers, use the same identifier for retries of the same logical operation and a new one for a genuinely new search. A client-side button lock alone cannot prevent duplication after a refresh or a network interruption; server-side handling must define that behavior.

Credit or billing semantics should be visible before submission and consistent with the backend. Avoid promising a refund rule in the interface unless the service actually enforces it.

Make the result reviewable

A recognition result is a candidate for the user to check. Display the identifying information clearly and give the user a way to compare the result with the intended song. Keep “no match”, “audio unavailable” and “request failed” distinct so the next action makes sense.

For developers, the main lesson is to design capture, submission and result review as separate steps. That separation improves error recovery and gives users a clearer understanding of what the browser is doing.

Example product homepage: https://www.humtosearch.app/