Audio Bleed in Mock Interview with Another User's Speech Incorrectly Attributed to Interviewer (Jim)

[LJY2000-max]

Description

During a mock interview session, a severe session leakage issue occurred. While I was in the interview, I suddenly heard another student's voice answering a question through my headphones.

More critically, not only did this audio bleed occur, but the system also incorrectly transcribed this external audio and attributed it entirely to the AI interviewer (Jim). As shown in the left Transcript panel of 截圖 2026-09-29 晚上10.48.27_2.jpg, there is a segment saying "Uh, I think my approach will be using the two pointers...". This was clearly another student's spoken answer, yet it was recorded in the Transcript as Jim's speech. This indicates cross-room data contamination when handling audio streams or data broadcasting, along with a severe logic error in speaker role binding.

Steps to Reproduce

I cannot provide exact steps to reproduce this, as this is the first time I've encountered it (seems to be an intermittent bug).

1. Start a mock interview session normally.
2. During the session, sudden audio bleed happens.
3. Observe that another person's speech is incorrectly transcribed and displayed as Jim's statement in the Transcript panel.

Expected Behavior

• Audio Isolation: Each user's connection must be strictly isolated. Users should never hear the voices of other interviewees.
• Role and Data Accuracy: The interviewer's (Jim's) channel should only output AI-generated responses from the system. It should never mix in or transcribe any human user's audio data. The Transcript should correctly map to the respective room and speaker roles.

Actual Behavior

Audio bleed occurred, and the system incorrectly routed another user's transcribed audio to the current session, writing it into the Transcript and tagging it as a statement from the interviewer, Jim.

Attachments

• 截圖 2026-09-29 晚上10.48.27_2.jpg

[jserv]

@LJY2000-max No other open or closed issue reports this, so this thread stands on its own. It needs a few facts before anyone can chase it, because the two explanations in your report have very different fixes and the evidence so far does not separate them.

On the room side: a room name is the prefix plus eight random base36 characters, drawn from the system CSPRNG (suffix in src/web/token.rs, used by room_and_provider in src/web/pool.rs). Two candidates landing in one room by accident is not a plausible cause, so cross-room contamination would mean something else, and naming it needs the room. Please post the room=interview-... line from your terminal log, and, if a classmate was interviewing at the same time, whether theirs differed.

What would tell the two apart:

1. Do you share a LiveKit project or a Gemini API key with other students, for example one key handed out for a course, or did you set up your own?
2. Were you in a shared space where the other person was audible, and were you on headphones the whole time or on speakers with the mic open? A voice the microphone picks up reaches Gemini as candidate audio, and if the transcript then labels it as Jim, the bug is in the role binding rather than in the transport.
3. Does that segment also appear as candidate speech anywhere in the transcript, or only as Jim's?
4. The terminal log around the time of that segment, redacted of keys and tokens. The timing lines and any Gemini requested a transport restart or reconnect near it matter.

If the saved report carries the same misattributed line, say so, since the report is generated from the same evidence and that would put the mislabeling upstream of the transcript panel.