Something is wrong in the room
Updated 25 August 2026 Applies to: Web app · iOS · Android · Windows · Browser extension
Three things go wrong in a room and they have three different fixes. Nobody can hear you, which is nearly always a permission or a device. The room dropped, which is nearly always the network. Or the advisers will not let you in, which is nearly always the microphone again.
Before any of it: the state of the room
In development 2026-08-24
The client is being built and no room has opened for anybody yet. These three answers are written from the design of the audio path and from what the layer underneath it does today. They are published now so that the first person to hit one of these is not the first person to write about it.
Nobody can hear me, or I cannot hear the advisers
Two causes cover almost all of it. Either the browser was never given the microphone, or it has the wrong device. Set the site permission to allowed and reload, then pick the device you are actually wearing. If you can hear the advisers and they cannot hear you, it is the first one. If you can hear nothing at all, it is the second.
01
Check the browser is allowed to use the microphone
A permission prompt that was dismissed once is remembered as a refusal. Open the site permissions for this page and set the microphone to allowed, then reload.
What you should see. The room showing your input level moving when you speak.
02
Check the right device is selected
Plugging headphones in after the room opened leaves the old device selected. Choose the device you are actually wearing rather than the one that was there at the start.
What you should see. The device name matching the one on your head.
03
Check the operating system has not muted the input
A hardware mute switch on a headset, and a system level input mute, are both invisible to the page. Both are more common than a fault in the room.
What you should see. The system input meter moving while you speak, before you go back to the room.
04
Reload the page rather than rejoining twice
A reload rebuilds the audio path from the top. Two sessions of the same room open in two tabs will compete for the microphone and neither will behave.
What you should see. One tab, one room, and your own voice registering.
If that did not work
Leave and rejoin on a different browser. Audio faults that survive a reload and a device change are usually the browser rather than the room, and knowing which it is tells us what to fix. Send us the browser and the version when you write.
The room dropped and I was disconnected
Rejoin from the same link. A dropped connection is not a destroyed session, and the transcript written up to that point is already saved. If it drops again within a minute, the network is blocking the audio path rather than the page.
01
Rejoin from the same link
A drop is a connection ending rather than a session being destroyed. The room is the same room while it is still inside its scheduled length.
What you should see. The same personas, with the argument where you left it.
02
If rejoining fails, check what your network allows
Real time audio needs outbound UDP. A corporate network that blocks it will connect the page and fail the audio, which reads as a room that drops the moment it starts.
What you should see. The room holding on a different network, such as a phone hotspot, which tells you the block is on the first one.
03
Read what survived
The transcript up to the drop is written as the session runs. What you lose is the part of the argument that had not happened yet.
What you should see. The transcript ending at the point the connection did.
If that did not work
A network that blocks real time audio is a known limitation rather than a fault we can fix from here. Corporate networks, some hotel networks and a few virtual private networks all do it. The roadmap carries what we intend to do about the ones that can be worked around.
The advisers talk over each other, or will not let me in
Just speak. Speech takes the floor and the persona holding it stops inside its sentence. There is nothing to press and no gap to wait for. If you speak and nothing happens, the room cannot hear you, and the audio answer above is the one you want.
01
Speak rather than waiting for a gap
Speech takes the floor. There is no button, no raised hand and no queue. If you wait for a pause you will wait through the whole exchange, because the room is built to keep arguing.
What you should see. The persona stopping inside its sentence rather than finishing it.
02
If nobody stops, check the microphone first
A room that will not let you in and a room that cannot hear you look identical from the outside. The audio steps above are the first thing to rule out.
What you should see. Your input level moving, which separates the two.
03
Expect the personas to talk against each other, and not over each other
Exactly one persona holds the floor at a time. Disagreement between them is the signal rather than a fault, and the room deciding who speaks next is the mechanism working.
What you should see. One voice at a time, from a fixed position, with the handover audible.
Why this happens
Every other product in this category takes turns by writing. A room that argues out loud has to decide who speaks next, and it has to give the floor up the instant a human wants it. That is the whole mechanism, and it is why interrupting feels wrong for the first minute and obvious after it.
Still stuck
Write to support@tingvar.com. A person replies within 2 business days, Monday to Friday. Tell us the browser, the device and roughly when it happened, and leave the content of the session out of it.