How to report an audio problem so support can reproduce it
A useful audio support ticket says what you expected, what you actually heard, and how someone else can repeat the check. Start with one short reference in the failing setup. Record its result, change one factor, and record the result again. You do not need to upload a private meeting, song, or microphone recording to describe most routing problems.
Start with the smallest reproducible problem
“My audio is broken” leaves the support team to guess whether the problem is capture, playback, one channel, one application, or one output. A narrower statement helps: “The left-only reference plays in both ears through this USB headset, but plays only on the left through the laptop speakers.” Even if you do not know the cause, you have identified two observable paths.
Use the WaveLocus audio test for a basic playback problem, the left/right test for routing, or the microphone test for capture. Begin at a low physical volume. Keep the same reference and settings when you repeat it. A familiar song can be useful background, but a short known signal is easier for another person to reproduce without a streaming account or a particular recording.
Record the path, not just the device name
Write down the computer or phone, operating system, browser, selected output or input, connection, and endpoint. “Headphones” may mean wired headphones in a laptop jack, a USB headset, or Bluetooth earbuds. Those paths can behave differently. If a display, receiver, interface, dock, or adapter sits between the computer and speaker, include it. For a microphone problem, name the selected input separately from the playback output.
Record the local time and whether the fault happens every time or only after an event, such as connecting a display or starting a call. Support teams commonly ask for reproducible steps, timing, environment, and what has already been tried. Google's Chrome support preparation guidance also warns people to remove sensitive information before submitting troubleshooting data. You do not need to collect every possible detail in advance. Include what affects this specific path.
Make one comparison before writing a conclusion
- Describe the starting setup. Note the active browser, reference, selected audio device, connection, and comfortable physical volume.
- Run the reference once. Record the exact observation: silent, one side missing, crackling, intermittent, or unexpectedly quiet. If a page shows “playing,” say that separately from what you heard. A playback indicator cannot confirm sound reached a speaker.
- Change one factor. Try another output, browser, cable, or source device, whichever is safe and relevant. Stop playback before touching a connection. Keep the reference and other settings fixed.
- Repeat and compare. Say whether the observation changed, stayed the same, or remained unclear. Do not turn that single comparison into a hardware verdict.
- List only changes you actually made. If you also changed volume or an operating-system setting, disclose it. The comparison is less controlled, but an honest record is still useful.
If the issue is intermittent, record the event that precedes it and how often it occurred in the attempts you made. “Twice in five short plays after connecting the dock” is more useful than “randomly.” Do not manufacture a repeat count or claim that a fault was reproduced when it was not.
Separate observation from interpretation
These distinctions matter because a browser sees only part of the path. A generated signal may be attenuated or routed differently after it leaves the page. A local microphone meter does not reproduce a remote call. The report should preserve that uncertainty rather than hiding it behind a confident diagnosis.
Use the evidence pack, then check it yourself
In guided diagnosis, record the setup, observations, and controlled change. The Support Evidence Pack can turn that local session into a support-ticket text, reproduction steps, a GitHub issue, or downloadable JSON, CSV, and printable HTML. The formats present the same structured facts; they do not add proof that was never collected. Read the preview before sharing. Correct missing or inaccurate details in the session, then export again.
If you need a compact ticket, use this order: problem statement; expected result; actual result; exact reproduction steps; audio path and relevant software versions; one comparison; frequency of occurrence; and what you have not established. GitHub's bug-report guidance likewise distinguishes reproduction steps, expected versus actual behavior, and environment. A screenshot can show a selected output or error message, but it cannot prove what you heard.
Protect private information
Do not paste account tokens, full meeting links, participant names, private files, or a raw microphone recording into a public ticket. Check downloaded reports and screenshots for names and device identifiers before sending them. The WaveLocus report is assembled from the local diagnostic session and does not include raw audio, but information you type into that session may still be personal. Decide what the recipient needs, and redact the rest.
Keep the original local result until the support team has enough information, then delete it if you no longer need it. If local browser storage is unavailable, copy or download the report before leaving the page. Nothing in a support pack replaces the recipient's own privacy or security instructions.
What the report cannot prove
A clean report is not a calibrated audio measurement, manufacturer diagnosis, or proof that a problem affects everyone with the same model. It is a reproducible description of one observed setup. If there is visible damage, heat, an unexpectedly loud output, or a suspect electrical connection, stop testing and use qualified support rather than trying further browser signals.
Once support replies, repeat the same reference after one suggested change and add the new observation. That creates a useful before-and-after record. If the problem disappears, say which change preceded it without asserting that you found the only cause.
Sources and method
This guide uses WaveLocus's local diagnosis and support-pack workflow. Google's support guidance informs the environment, reproduction, and privacy checklist. GitHub's issue guidance informs the expected-versus-actual structure. Neither source verifies any individual audio fault.