Why a 20-Year-Old Chinese Broadcast Software Team Is Opening to International Stations Now

By the KAVANA engineering team — June 2026

We have been building broadcast automation software since 2005. In that time, we have shipped to more than 500 radio stations across China, survived the transition from tape to digital, watched the rise and fall of half a dozen "AI will replace broadcast" hype cycles, and kept the lights on at stations in places like Fugong County in the Nujiang mountains — a town of 30,000 people with a local FM station that still needs to go on air every morning at 6:00. We were not thinking about international expansion. Then, over the course of about eighteen months, three things changed our mind.

This post is not a sales pitch. We want to explain our actual reasoning, describe what we have built (and what we have not), and let broadcast engineers and station operators abroad decide for themselves whether any of it is relevant to them.

Why Now: Three Converging Forces

The first force is saturation. The Chinese broadcast regulatory environment has consolidated aggressively over the past five years. County-level stations that once ran separate technical systems have been merged into prefecture-level unified playout centers. That compression is good for efficiency and bad for software vendors who sold per-station licenses. We are not the only company that noticed this ceiling.

The second force is that local GPU inference became cheap enough to change what "broadcast AI" actually means. In 2022, running a credible text-to-speech model locally required hardware most stations could not justify. By 2024, a single consumer-grade GPU card could run a voice synthesis model at real-time factors well below 0.1 — fast enough to synthesize a 90-second news segment in under 10 seconds, inside the station's own building, with no cloud round-trip and no data leaving the premises. That matters enormously for broadcast compliance in any jurisdiction that cares about content provenance and audit trails. We built our AI pipeline around local inference precisely because our Chinese customers demanded it. It turns out that demand is not unique to China.

The third force is that we started getting inbound inquiries from outside China without doing anything to solicit them. A broadcaster in Southeast Asia found our GitHub organization. A media tech consultant in Europe reached out after reading a Chinese-language technical post that had been machine-translated. These were small signals, but they told us that the specific problem we solve — keeping a small or medium-sized radio station on air reliably, with increasingly capable AI assistance, without requiring a large technical staff — is not a China-specific problem.

What Twenty Years of Failure Looks Like Up Close

We would rather describe our hard-won lessons than our feature list, because the lessons are more honest.

Lesson one: automation that cannot explain itself to a non-engineer will be bypassed. Early versions of our scheduler relied on logic that the station's music director could not interrogate. The result was that operators would override the automation for reasons we could not diagnose, the overrides would accumulate, and eventually the system would drift so far from its intended state that nobody trusted it. We rebuilt the compliance audit trail from scratch to make every automated decision visible as a human-readable log entry. The engineer can always see exactly why a particular segment was placed, rejected, or flagged.

Lesson two: the last-mile reliability problem is underrated. A station in a rural county in Hunan province has the same on-air obligation as a station in Shanghai. But the IT support infrastructure is radically different. We spent years building our watchdog process — DOG, as we call it internally — specifically to handle the scenario where the main playout application crashes, the network connection to the central server drops, and the on-duty operator has gone home. DOG monitors the broadcast chain, can restart failed components, can fall back to a pre-cached emergency program, and can phone home to report its status over a reverse SSH tunnel even when the station's primary network is unreachable. That is not a feature we designed for a product brochure. It is a feature we designed because stations called us at 3 a.m.

Lesson three: compliance is an architecture decision, not a module you add later. Chinese broadcast regulation requires three-tier content review, real-time audio fingerprinting for compliance monitoring, and audit logs that survive system crashes. We built what we internally call the wav9 audio firewall — a per-frame content inspection layer that runs below the playout engine — because regulators required it. The specific rules differ by jurisdiction, but the architectural pattern of "inspect content before it reaches the transmitter, log everything, never let the audit trail be the bottleneck" is applicable anywhere.

How We Compare to NexGen, WideOrbit, and the Rest

We have studied the major Western broadcast automation platforms. We respect the engineering behind them. We also think the market has a meaningful gap that they do not fill well.

The incumbent platforms were designed in an era when a station's technical complexity was proportional to its budget. A large market station with a full engineering team could afford a WideOrbit or RCS deployment. A small market station would use something simpler and accept the limitations. The AI wave is collapsing that assumption. A station with three full-time staff can now, in principle, run an AI news host, generate localized weather segments, synthesize program promos, and flag compliance issues — if the software infrastructure supports it. The incumbent platforms are adding AI features, but they are adding them as cloud services on top of architectures that were not designed for local inference, local data residency, or the specific paranoia that broadcast regulators tend to have about where content is generated.

Our architecture was designed differently from the start. KAVANA-MGR is the playout and scheduling engine. KAVANA-ADV handles ad automation and traffic. DOG is the watchdog layer. The AI Host system — which we call AI Three Gods for the three synthesis pipelines it orchestrates — runs entirely on local GPU hardware by default, with cloud fallback only when the station explicitly permits it. The compliance system including wav9 sits between all content sources and the transmitter.

We are not claiming to be more feature-rich than WideOrbit on any individual dimension. We are claiming to be more coherent as an architecture for the specific scenario of a small-to-medium station that wants AI-native operations without cloud dependency.

The other meaningful difference is price. We do not publish list prices, but the order of magnitude is different. A full five-module deployment for a single station is priced for a county broadcaster's budget, not an enterprise SaaS contract. That matters when the station you are talking to has four people on staff.

The Data Residency Question You Are Probably Thinking About

If you are a broadcast engineer reading this outside China, you are probably wondering: if we let a Chinese software system into our broadcast chain, what leaves the building?

Fair question. Here is the honest answer.

By default, in a standard KAVANA deployment, the answer is: your broadcast audio, your logs, and your operational data stay on your hardware. The AI synthesis runs on your GPU. The compliance monitoring runs on your server. The watchdog telemetry goes to whatever monitoring endpoint you configure, which can be your own. We do not operate a mandatory cloud backend. There is no phone-home license check that sends usage data to us.

What does leave the building, if you use cloud TTS features: the text of what is being synthesized goes to the cloud TTS provider (Alibaba Cloud CosyVoice or MiniMax, in our current pipeline). You can configure the system to use only local inference, in which case nothing leaves the building. The configuration is explicit and documented.

We recognize that "trust us, we're Chinese" is not a convincing data residency argument to a European broadcaster operating under GDPR, or an American broadcaster thinking about FCC audit trails. That is why we are investing in making the data flows auditable and configurable at the architecture level, and why we have published the wav9 audio format specification as an open standard on our GitHub organization. The spec is there. You can read it, implement your own tools against it, and verify what the system is doing.

What We Have Ready and What We Have Not

We try to be honest with ourselves about this, so we will be honest with you.

Ready: The core playout and scheduling engine is mature. Five hundred station-years of production operation is not nothing. The watchdog and remote management architecture works in conditions that would break simpler systems. The AI synthesis pipeline — local GPU inference for TTS, AI-generated news segments, automated compliance flagging — is in production at stations that cannot afford to experiment. The wav9 compliance layer is documented and open. Our documentation in English is incomplete but exists and is growing. We have a GitHub organization at github.com/kavanafm with public repositories for the wav9 spec, English documentation, and clock template libraries that are format-independent.

Not ready: Our UI has not been internationalized beyond simplified Chinese, traditional Chinese, and basic English labels. If you need a fully English-language operator interface, we can provide it for new deployments, but it is not our default build. Time zone handling is complete for UTC+8 and adjacent zones; edge cases in zones with unusual DST rules have not been tested. Our customer support is currently in Mandarin. We have one engineer who handles international communication in English, and he is good, but one engineer is one engineer. We do not have a local reseller or integration partner outside East Asia. If you need someone to come to your facility, that is a conversation we need to have about logistics.

We also have not completed independent third-party security audits to international standards. We have completed Chinese cybersecurity-level requirements (等保 Level 3), which are rigorous but not directly comparable to SOC 2 or ISO 27001. We are working on this, but we are not there yet.

Who This Might Actually Be For

Based on the inbound inquiries we have received and our own analysis, we think the stations most likely to get value from talking to us are:

Community and regional stations in countries where broadcast automation has historically been dominated by a small number of expensive vendors, and where a station's technical staff is one or two people. The architecture we have built is specifically for this operational profile.

Stations in markets where local-language AI synthesis is technically possible but not commercially available from major vendors. We have built the infrastructure to run any compatible local TTS model. If you have a language model that speaks your language, we can integrate it into the broadcast chain.

Broadcast groups in Southeast Asia, South Asia, and parts of Africa and the Middle East where Chinese media technology has an existing deployment footprint and where working with a Chinese vendor is not politically complex.

Media tech researchers and developers who want to understand how a production broadcast AI pipeline actually works, as opposed to how it works in a demo environment. We are open to technical conversations and collaborations that do not require a commercial agreement.

What We Are Asking For

We are not asking you to buy anything. We are asking for conversations.

If you are a broadcast engineer who read this and thought "that watchdog architecture is interesting" or "I have exactly this last-mile reliability problem" — we want to talk to you. If you are a station manager who is being quoted prices by the incumbent vendors that do not fit your budget and you want to understand what the alternatives look like — we want to talk to you. If you are a media tech investor or researcher who wants to understand the Chinese broadcast software market from the inside — we especially want to talk to you.

The best way to reach us is email: international@kavanafm.com. We also maintain an open workspace for technical discussion and documentation at kavanafm.com/en. Response time is typically within 48 hours. For technical questions, please include a brief description of your station's technical environment — number of channels, current automation platform if any, and the specific problem you are trying to solve. We will give you an honest answer about whether we can help.

We have spent twenty years solving broadcast reliability problems for stations that most software vendors do not think about. We think some of what we have learned is useful beyond China's borders. We are ready to find out if we are right.

KAVANA is developed by Hunan ShengGuang Technology Co., Ltd. (湖南声广科技有限公司), incorporated 2012, team active since 2005. We hold a broadcast production and distribution license (湘字第00565号) and operate under Chinese cybersecurity Level 3 certification. Technical documentation and open specifications: github.com/kavanafm.

Originally published at https://www.kavanafm.com/blog/en/why-a-20-year-old-chinese-broadcast-software-team-.html

Draft assisted by Codex/DeepSeek, reviewed and edited by KAVANA engineering team.