PTE Speaking: my mic didn't work — the honest 2026 guide to silent recordings

The two silent-recording failure modes (they get confused all the time)

“My mic didn't work” is a single sentence that covers two very different failures. Which one hit you determines whether Pearson will re-open the test, and it determines whether our mock would have caught it before scoring.

Failure 1 — the recorder never opened. You spoke into the mic, but the browser or the test-centre workstation never actually captured a track. You get a zero on that item because the file uploaded to Pearson's scoring engine is empty. This is a hardware or permissions problem: a Bluetooth headset that disconnected, a browser that never got mic permission, a driver crash between the tone check and the actual task.

Failure 2 — the recorder captured silence. The file uploaded fine, has the right duration, and even shows waveform activity — but the speech is inaudible. Usually the mic level was set too low at check-in, or the mic was pointed away from you, or there was a mute switch on your headset cable you didn't notice. Pearson's scoring engine received the file and ran it, and the AI has to score what it heard: nothing.

Both failures produce a low score, but only Failure 1 is grounds for a technical review under Pearson's current policy. Failure 2 is treated as your responsibility — you were shown the mic level meter at check-in and confirmed the equipment.

What Pearson actually does about it (48-hour technical-review window)

Pearson's Academic Test Taker Handbook, July 2025 edition, page 16, is the primary source. The clause reads: “If you experience a technical issue during your test, you must submit a technical review request within 48 hours of your test appointment via the Help Center.” The identical clause appears in the October 2025 PTE Core Test Taker Handbook on page 14.

Three details are load-bearing:

• The window is 48 hours from your appointment, not 48 hours from when your score released. If your score takes 2 days to release, the window has already closed by the time you see the problem. This is the single most common way candidates miss the deadline — they wait for the report before filing.
• You file at pearsonpte.com/help-center, using the “Technical issue during test” request type. There is no form on the score report itself.
• A successful technical review most commonly results in a free re-test, not a rescore of the corrupted file. Pearson does not manually re-listen to a silent recording; there is nothing to re-listen to.

Do not confuse a technical review with a rescore or an academic review. Those are for score disputes on a properly-captured attempt. If your mic didn't record, a rescore of nothing will still return nothing.

Why silent recordings score at the floor, and why some mock platforms hide it

Pearson's scoring engine is trait-based. Speaking items are scored on Content, Oral Fluency and Pronunciation. When the audio file is silent, there is nothing to score any of those on. The engine returns the trait floor for each, which rolls up to an overall item score at the bottom of the 10–90 band.

On our platform we hold the same line: a silent capture is scored at the floor, and we say so out loud on the report. This is a deliberate design decision from 2026-07-08 (see the P0 fix in the 2026 scoring changes ledger): before that fix we were quietly flooring silent items to 10 without flagging them, exactly the same behaviour that most competing mock platforms still ship.

That silent floor-scoring is the biggest quiet lie in the PTE mock market. A learner who spoke perfectly well into a broken mic gets a 10 on Read Aloud, thinks their speaking is catastrophic, and rebuilds a plan around a phantom weakness. We now surface the capture failure as a bold red block on the report — “⚠ No recording captured for this task” — so you know the number reflects a hardware problem, not your English.

How our mock detects the failure before scoring

Every speaking item on our mocks runs a three-stage capture pipeline: the browser MediaRecorder streams a WebM chunk, we upload it to Supabase Storage, and we call our transcription service for a text version. A silent recording gets caught at two points along that pipeline:

1. At upload. If the audio blob has zero bytes — i.e. the recorder never wrote a single frame — the upload endpoint rejects it with an empty error. That is the harshest Failure-1 case (recorder never opened, tab lost mic permission mid-task, headset unplugged).
2. At transcription. If the file uploaded but the transcription service returns no words, the response is stored with the internal sentinel (no spoken answer captured). This catches every Failure-2 case (mic was on but too quiet, or the wrong device was selected in the browser).

Downstream, two things happen automatically:

• The AI scoring prompt is explicitly told to look for that sentinel. When it sees it, the item scores the honest floor of 10 and the AI writes a user-facing note like “you did not record a spoken answer for [task]” — never a system-y message about missing transcripts.
• The report renders a red “⚠ No recording captured for this task” block in place of the audio player, so the low score is contextualised as a capture failure, not a speaking failure.

The end result: our score report tells you when to worry about your speaking and when to worry about your setup, and those two get different playbooks. It is the specific bug we shipped fixes for in early July 2026 (the whole speaking-flush-on-unmount + audio-upload-MIME-rejection sequence) and the reason our mocks are meaningfully different from the free alternatives that just show “Speaking 10” and let you draw the wrong conclusion.

Prevent it happening on the real test: the 4-step mic prep

At the test centre, the workstation is not yours and the pre-test system check is faster than you think. Four habits reduce the failure rate to near zero:

1. At check-in, watch the mic level meter carefully. Speak your name at the volume you plan to use during Read Aloud. The green bar should reach the two-thirds mark; if it stays low, flag it to the invigilator before the test starts.
2. Position the mic 2–3 cm from the corner of your mouth, not directly in front. Directly in front picks up plosive pops that AI transcription drops; 2–3 cm off-axis captures the same signal cleanly.
3. During the first Read Aloud, project. If the mic was fine at check-in but you softened your voice for the real test, your levels drop. The scoring engine does not know you were nervous; it hears a quieter file.
4. If a task feels off — a delay, no beep, no waveform on the record indicator — raise your hand immediately. Do not wait to see if the next task works. Invigilators can log a mid-test technical event and it strengthens any later technical-review request.

Before the real test, run our free full-length mock at your usual home setup. If a task comes back with the “No recording captured” flag, fix the underlying cause (headset, permissions, browser) before you spend AUD 445 on the real sitting.

If it's already happened to you: the recovery playbook

Assume the failure has just happened and you are inside the 48-hour window. Do these five things, in order.

1. Note the exact appointment time in your local zone. The 48-hour clock runs from that, not from now.
2. Write down the specific tasks affected, in order. “Read Aloud item 3 and Repeat Sentence items 1 and 4” is a stronger case than “the speaking section.”
3. File the technical review at pearsonpte.com/help-center under the “Technical issue during test” request type. Include the test ID, the appointment time, and the specific tasks. Do not wait for the score.
4. If you noticed it during the test and raised your hand, mention that in the request and name the invigilator. Their event log corroborates yours.
5. If you did not raise it during the test, be honest about that. Claiming otherwise when Pearson has the invigilator log is the fastest way to get a request denied.

Expect a Pearson response inside 5–10 business days. If they approve, you typically receive a free re-test voucher; if they deny, the score stands. Either way, use the interval to keep prepping — an approved retake is worth nothing if you are not sharper for it.

If the failure is on our mock rather than a real test, there is nothing to file. Reset your mic setup and re-run the specific task from our task practice bank — it costs nothing and lets you rebuild confidence one item at a time.

AU, NZ and Canada — country-specific notes

Two country-specific quirks are worth calling out because they change what happens after a failed test.

• Australia (DHA). A failed and re-tested PTE Academic does not affect your DHA points calculation as long as you submit the successful score. Prior failed attempts do not appear on the SRC report you send to Home Affairs. See our PTE for Australia PR page for the current per-skill minimums.
• New Zealand (INZ). Immigration New Zealand pulls scores from Pearson directly via SELT URN. A cancelled or reviewed attempt is not surfaced. If you sit twice and the second attempt clears the threshold, only that clean attempt needs to be shared.
• Canada (IRCC). PTE Core scores flow through the IRCC auto-retrieval channel. IRCC only receives the specific test result you nominate, so a mic failure on an earlier attempt has no bearing. Our Core vs Academic explainer covers which stream accepts which test.

Common thread: a failed sitting is a bad afternoon, not a permanent record. Nobody downstream sees your capture problem — they see the score you nominate. File the technical review, and if it doesn't land, retake once you've fixed the setup.