24 AUG 2026
Tingvar in the browser
WebRTC and the Web Audio API are native to the browser, so a room is a page rather than a download.
19 AUG 2026
What there is to show, and what is measured
What there is to show, and what there is not
Not yet produced
The room at desktop size, which is the surface every other one is a port of. There is no screen to photograph yet.
Not yet produced
A picture of the room in use. There is no room to photograph. A design render labelled as one is allowed on this page and has not been made, and it would never be allowed in a store listing.
Measured
Voice to voice
1471 ms
Median, on the bench in us-central1, with a real media server
MEASURED 2026-08-19, 122 readings
Real human sessions
0 sessions
Have taken place. Every measured turn so far used pre-rendered audio
MEASURED 2026-08-23, 1 reading
The figure on the left is the decision layer answering, measured against a real media server rather than a simulation. The figure on the right is the reason the first one is not enough. Both sit on the evidence page with the method, the sample size and the five stages the median breaks into.
Why the browser is first
The person deciding whether a team should use a tool like this is at a desk. They have a proposal open in one window and half an hour before the next meeting. A tool they cannot open in the window they are already working in does not get evaluated, it gets bookmarked.
That is the whole argument for building the browser surface first, and it is also the argument for saying plainly that it is not finished. An evaluator who opens this page, reads that the client is in development, and comes back in a month has lost nothing. An evaluator who signs up expecting a room and finds a form has been told something untrue by us.
The browser is also the surface this product is built for, and every other surface on this site is a port of this one. Which surface a product starts on is a choice, and it is a choice each one publishes for itself. AI Group Call ships on iOS and Android and states no web client. Read on their own pages at aigroupcall.app, and the JSON-LD on their own homepage, on 23 August 2026.
What we have not yet measured about this surface: End to end barge-in latency, from human voice onset to the speaking persona falling silent at the client. The internal pump has been measured. The media server leg and the client leg have not, so no end to end value exists, and an internal stage is not a product measurement. This row is dated 5 Sept 2026.
What runs here
| Surface | State today | What it would add over the browser |
|---|---|---|
| Web app | Baseline | Nothing. This is the surface the product is built for |
| iOS | Not shipped | A session that keeps running with the app in the background, and one you can hold while you walk |
| Android | Not shipped | A session that keeps running with the app in the background, and one you can hold while you walk |
| Windows | Not shipped | A window that runs in the background, and a session that survives the machine going to sleep |
| Browser extension | Not shipped | A launcher that carries a proposal into a room from the page you are already reading |
| MCP server | Not shipped | A room another program can open, with nobody at a browser |
The table above is which surfaces exist. The one below is what the browser can do, and what a native surface would add to it. Nothing has shipped on any surface, this one included, and each surface carries its own state on its own page: Windows is not planned at all.
| Capability | Browser | A native app |
|---|---|---|
| Joins a room and holds a voice call | Yes | Yes |
| Each persona in a fixed position in the stereo field | Yes | Yes |
| Mono fallback for one earbud or a laptop speaker | Yes | Yes |
| Live transcript, attributed line by line | Yes | Yes |
| Interrupt by speaking | Yes | Yes |
| Runs with the window in the background | Not decided | Yes, by design |
| Survives the machine going to sleep | No | Not decided |
| Anything to install, and anything to ask IT for | No | Yes |
Two rows in that table say Not decided. They are the rows a native surface exists to win, and writing a Yes into either of them before the client runs would be inventing a capability. The rows marked No are the ones the browser loses, and they stay in the table.
What you need
| Requirement | What it means |
|---|---|
| A current browser | Chrome, Edge, Safari and Firefox on their current versions carry WebRTC and the Web Audio API, which is what a live room needs. |
| A working microphone | The browser asks for permission when you join a room, and not before. Refusing it means the session does not start, and the page says so rather than opening a room you cannot speak in. |
| Headphones | A laptop speaker feeding back into a laptop microphone is a reliable way to make any voice product unpleasant. This is a requirement rather than an upsell. |
| A connection that holds a call | A poor connection costs you audio quality first. There is no lower fidelity mode that hides it. |
| A room you can talk in | It is a spoken conversation and you will be interrupting people. Open plan is the honest problem here. |
Headphones or a headset make a real difference, for two mechanical reasons. An open microphone sitting beside a loudspeaker hears the personas as well as you, so their audio arrives back in the room. Separating the voices across the stereo field is also what makes a rapid change of speaker followable, and what lets you attribute a sentence to a persona afterwards. If you are on one earbud or a laptop speaker, panning does nothing, so the room falls back to mono. The fallback attenuates no persona: every voice stays at the level it would have had, and you lose the placement rather than a speaker.
Capabilities the client requires
| What | What it is for |
|---|---|
| A secure context | The page is served over HTTPS. A browser refuses microphone capture on an insecure origin, so this is a precondition rather than a preference. |
| getUserMedia audio capture | The call that opens the microphone. It is what the permission prompt is attached to. |
| RTCPeerConnection with Opus | The media path. Opus is the codec the room negotiates for speech. |
| AudioContext | The Web Audio graph the room is built on. Without it there is playback and no placement. |
| StereoPannerNode | What puts each persona in a fixed position in the stereo field. Where it is absent the room falls back to mono. |
| A persistent WebSocket | The control channel that carries turn taking, the transcript and the interrupt signal. It stays open for the length of a session. |
A runtime can expose all six of those and a session can still fail, on echo cancellation, on device enumeration or on an autoplay rule. That is why the list below is separate: it records what has actually been run, and this one records only what the client needs to exist.
What has been run, and on what
| Browser | Operating system | Version tested | Date tested | Verdict |
|---|---|---|---|---|
| Chrome | Windows | None | None | Not tested |
| Chrome | macOS | None | None | Not tested |
| Edge | Windows | None | None | Not tested |
| Firefox | Windows | None | None | Not tested |
| Safari | macOS | None | None | Not tested |
| Safari | iOS | None | None | Not tested |
| Chrome | Android | None | None | Not tested |
Not tested does not mean does not work.
Permissions
| Permission | When it is asked | Why | If you refuse |
|---|---|---|---|
| Microphone | At the pre-session check, after the brief. Never before | The room is a conversation and your speech is what takes the floor | The session does not start. The page says so and offers the recovery route |
| Audio playback | At your first play gesture, which is not a permission prompt | A browser requires a gesture before it will play sound | Nothing plays until you press play. Nothing on this site autoplays |
| Camera | Never asked | There is no video in this product | Nothing to refuse |
| Screen share | Never asked | Screen sharing is not in the first version | Nothing to refuse |
| Notifications | Never asked | A notification prompt on a first visit is the category's worst habit | Nothing to refuse |
| Location, clipboard read and persistent storage | Never asked | None of the three is used | Nothing to refuse |
The microphone is the one permission this product requests, and nothing else on that list is ever asked for. Camera, screen share, notifications, location, clipboard read and persistent storage are all in the never column. This page asks for nothing. No permission is requested on this page at all, and the first prompt you will see arrives at the pre-session check.
Questions to answer before you install
Will it work on my work laptop, behind a VPN or a strict proxy?
The client needs two things from a network: a WebRTC media path for the audio, and a persistent WebSocket for turn taking and the transcript. Some corporate networks block both. We have not measured behaviour on corporate networks, and we will not guess: no reading behind our published latency figures was taken from behind a managed proxy. When the client ships, this row carries the networks a session was established from and the ones it was not.
What if I do not want to give a website my microphone?
The permission is asked once, at the pre-session check, and never on this page. You can revoke it in your browser at any time. Revoking it ends your ability to start a session and nothing else, so your account, your briefs and your past transcripts are untouched. A refused microphone never quietly turns a session into a listening seat: the session does not start, and the page says why.
What happens if I put the tab in the background, or the machine goes to sleep?
A browser throttles a tab you are not looking at: timers slow down and an operating system reclaims audio work from a background tab before it reclaims anything else. A machine going to sleep is harder than that, because it drops the media path and the control socket with it. Neither behaviour has been measured, no client exists to measure it on, and nothing on this page says a session survives either one. What is decided is that a session interrupted by us is not a session you pay for, and the refund terms say so.
Does it need an extension, a plugin or a download?
No. The browser carries WebRTC and the Web Audio API natively, so a room is a page. The separate extension surface is a launcher that carries a proposal into a room, and it is not needed to hold one.
Do I have to wear a headset?
No. Headphones or a headset are a recommendation on this page and never a condition of entry, and nothing is held back from you for using a laptop speaker instead. The two mechanical reasons they help, and what the room does when you are on one earbud or a speaker, are in the paragraph under the requirements table above. It is written there once rather than twice here.
What does a session do to a laptop battery?
A session runs 45 minutes of continuous capture and playback, which is close to the heaviest thing a browser tab can do: the microphone stays open and the audio graph keeps running for the whole of it. What that costs a battery has not been measured, because no client exists to run a session on, and a percentage invented here would be worth nothing to you. When the client ships, this row carries a figure and the machine it was taken on.
What do I need to run it?
Tingvar needs a current browser with WebRTC and Web Audio support, a working microphone, and a connection that can hold a voice call. Chrome, Edge, Safari and Firefox on their current versions all carry what it needs. Headphones are worth having, because a laptop speaker feeding back into a laptop microphone is a reliable way to make any voice product unpleasant. A poor connection costs you audio quality first.
Where the audio goes
To Google for speech recognition and synthesis, and through a media server we run. It is processed while the room is live, it is not retained, and it does not stay on your device.
What we keep
The brief and the transcript. Audio is discarded once the transcript is written.
Who can read it
You. Nobody at Tingvar reads, inspects or processes a transcript without your express written request on an active support case. Every authorised administrative access is time bounded, restricted to the session you named, and recorded in a tamper evident audit log.
How you destroy it
One control on the account page. It removes the brief, the transcript and the account together, and backups are purged within 30 days.
Where the recording goes
Tingvar does not store your session audio: it is processed while the room is live and no recording of it is kept. What persists is the transcript, the text of what you said and what each persona said, attributed line by line. Only the account that ran the session can read that transcript, and nobody at Tingvar reads one without your written request on a support case. You can delete any session yourself, and deletions are purged from backups within 30 days. The retention schedule is published at tingvar.com/trust/your-data.
Billing on this surface is ours. You buy on the web and you cancel on the web from your account settings, with nobody to talk to first, and deleting your account cancels the subscription at the same time. The refund terms carry the window and what happens when a room drops part way through.
Where to go from here
IDLE
Nobody has used this yet
Zero real human sessions have taken place. Every measured turn to date used pre-rendered audio clips rather than a live human. What is built and verified is the decision layer: the turn-taking policy, the bid scoring and the configuration guards, with 619 automated tests passing and 81.78 % combined coverage. Everything there says the system works. Nothing there says anyone wants it, and being first is a real risk you are taking.
The accessibility statement, with the conformance position and the gaps we know about