Latency Spike in a Remote CART Feed
You provide remote CART to a deaf graduate student in a seminar held on a videoconference platform. Baseline latency from your keystroke to the student's screen is about 250 ms, which is acceptable to them. In the second hour, latency spikes to two to three seconds and text arrives in bursts of eight to ten words, then freezes for a second. The student reports that the text 'jumps' and they lose their place. Your local realtime window is clean and current. There is a 15-minute break in 20 minutes. The caption integration is a third-party plug-in you did not configure, and you have no administrator access to the platform.
1. In what order do you diagnose this, and what do you rule out first?
Read the worked answer
Rule out yourself first, and cheaply: your local window is clean and current. That single fact tells you the writing and the translation are fine, and that the fault is downstream - network or the student's display path. So nothing about your writing changes.
Then work outward in order of cost:
- Connection. Check your own latency and packet loss to the platform, and ask whether anything else on your network changed at the two-hour mark - a backup, a sync client, a second stream.
- The plug-in's buffering. Eight-to-ten-word bursts followed by a freeze is the signature of line or phrase buffering, not of a slow pipe alone. If the plug-in waits for a buffer to fill before rendering, the student sees exactly this.
- The client side. Ask what settings the student has and whether they can switch to a word-by-word or scrolling view.
'Jumping' is a display symptom, not an accuracy symptom. Do not start rewriting or slowing down in response to it.
2. What do you change now, and what do you refuse to change?
Read the worked answer
Change the delivery path, not the writing.
- Ask the student to switch the display to word-by-word streaming if the plug-in supports it. That converts a two-second freeze into continuous small updates and largely solves 'losing my place.'
- Clear competing bandwidth on your machine.
- If you have a second delivery path - a browser-based viewer, a direct caption window - move the student to it and leave the plug-in out of the loop.
Refuse to change:
- Your writing speed or rhythm. Batching your output to match the buffering makes the chunking worse and puts you behind on the record.
- Your accuracy settings. This is not a translation problem and should not be treated as one.
If latency cannot be brought down, say so plainly. A student who thinks their own connection is failing will troubleshoot the wrong thing all seminar.
3. What do you document, and what do you tell the student and the seminar organizer?
Read the worked answer
Document with timestamps: the two-hour onset, the measured latency range, the burst-and-freeze symptom, the fact that your local feed was clean and current throughout, the plug-in's identity, and the fact that you had no administrator access to configure it. That record protects you if someone later asks why the feed degraded.
Tell the student what you observed in plain language - the delay is in the delivery path, not in the transcription - and give them the interim workaround now rather than at the break.
Tell the organizer three things: the fault is downstream of the reporter, the fix is in the platform or plug-in configuration, and a transcript will exist regardless. Offer a scoped post-session transcript as the durable accommodation if the live feed stays unreliable.
Then make the one request you can make: someone with administrator access needs to look at the caption plug-in's buffering settings before the next session.