Put captions on the audience’s own phones and you have moved your event’s weakest link. It is no longer the caption system: it is the access point in the ceiling of the plenary room, and it will fail before anything on your rider does.
This is the part nobody load-tests, so it is worth being specific about what goes wrong.
What actually breaks, in order
The join, not the reading. Once a phone is connected and following, a caption feed is a trickle. Text arriving as somebody speaks. The expensive moment is everybody arriving at once: five hundred devices associating with an access point, doing DHCP, resolving DNS and opening a connection inside the same three minutes while the room fills.
Client count per radio, before bandwidth. A consumer access point is happy with dozens of clients, not hundreds. Long before you run out of megabits, you run out of airtime: the radio spends its time managing associations rather than moving data.
The captive portal. Venue Wi-Fi that puts a login page in front of every device is the single most reliable way to lose half a room. People do not fight a portal while a keynote is starting; they give up.
2.4 GHz. If the room falls back to it, a few hundred phones share a band that also carries every radio mic, every clicker and the building next door.
What to ask the venue, in writing
- How many simultaneous clients per access point, and how many APs cover the plenary? Not “is there Wi-Fi”. A number, per room.
- Is there a captive portal, and can it be turned off for our event? If it cannot, plan around it (below).
- Is 5 GHz available across the whole room, or only near the stage?
- Is the guest network rate-limited per client? A cap is fine. A cap of 64 kbps with deep packet inspection is not.
What to do when the answers are bad
Print the code, do not only project it. People arrive late, and a code that only existed on a slide at 09:00 is invisible at 09:20. A room code can be reserved up to ninety days ahead on any paid plan, which means it can go in the printed programme, on the signage and on the badge.
Stagger the join. Put the code up while the room is filling, not when the first speaker starts. Twenty minutes of people drifting in is twenty minutes of joins spread out, instead of five hundred in one spike.
Keep the venue screen. This is the real answer to bad Wi-Fi, and it is easy to forget when the phone experience is the selling point: the captions also go to the room screen, over NDI into your switcher, over HDMI with a chroma key, or by opening the caption screen on any TV with a browser. Nobody needs a phone to follow the event in the language being spoken. If the network collapses, the room still reads.
What we can and cannot tell you about our own side
We can tell you our side holds: measured against the deployed system, one room carried five thousand concurrent phone connections with none refused. We recommend selling five hundred to a thousand per event, not because more breaks, but because above that the delivery time starts approaching our own quality target, and a caption that arrives late is a caption somebody read after the speaker moved on.
What that measurement does not tell you is anything about a real venue. It was five thousand connections from a machine, not five thousand phones through real access points in a real hall. Anyone quoting you a concurrency figure (us included) is describing their own server, not your building. The building is the part to check.