KINTO replaced a community radio station’s paid streaming with its own infrastructure: latency from ≈10 s to under 1 s and a monthly cost that fell by more than 90%.
Problem
The station streamed online through a paid third-party service, with high latency, no control of the stream, no real listener metrics, and a dependence on the provider to appear in radio directories.
Signals
- Market: A local audience that listens on web and mobile; radio directories require a compatible stream.
- Business: Recurring cost, and a goal of hundreds of simultaneous listeners at almost no cost.
- User experience: Latency and dropouts; school and corporate networks that block certain protocols.
- Support: WhatsApp and social links in the player; a widget for the station’s website.
How we understood it
- A specification first, and latency tests per protocol.
- Diagnosis of a hard fault: silent audio in the infrastructure.
- Analytics with the listener at 30 seconds as the key metric.
What we built and why
- Streaming app for the station’s PC.
- Cloud server with several outputs (real-time, low-latency and a directory-compatible format) that restarts itself.
- Web player with automatic protocol fallback and an embeddable widget for the station’s website.
Why this way: Some networks block certain protocols, so the player falls back from one to another on its own, and the server offers three outputs (real-time, low-latency and a directory-compatible format).
Transformation
-
Latency from ≈10 s to ≈0.3–0.8 s in real-time mode (≈2–3 s in low-latency mode).
-
Monthly cost cut by more than 90%.
-
real-time mode latency: from ≈10 s to ≈0.3–0.8 s (measured)
-
monthly streaming cost: ≈−90% or more (measured)
What we don’t know yet
- Audience and retention: no evidence.
