DEV Community: Qua Lekuch

The Actual Cost of Dead Air: What 20 Years of Station Outages Taught Us About Broadcast Economics

Qua Lekuch — Mon, 08 Jun 2026 03:06:48 +0000

The Actual Cost of Dead Air: What 20 Years of Station Outages Taught Us About Broadcast Economics

By the KAVANA engineering team — June 2026

When broadcast engineers talk about dead air, they usually frame it as a technical failure. The playout machine crashed. The audio card locked up. The network path to the remote studio dropped. Something broke. The conversation that follows is almost always about what broke and how to prevent it from breaking again.

That framing is incomplete. Dead air is not just a technical event. It is an economic event with a cascade of costs that extends well beyond the immediate outage window. After twenty years of supporting stations through failures — including the failures we caused, the ones we should have prevented, and the ones that were genuinely unforeseeable — we have developed a clearer picture of what dead air actually costs in practice, not in theory.

This post is an attempt to quantify that honestly. The numbers come from incident logs, customer conversations, and our own post-mortems. Where we are estimating, we say so.

The Thirty-Second Incident That Took Three Weeks to Resolve

In the autumn of 2019, a county-level radio station in Hunan province experienced thirty seconds of dead air during morning drive time. Not thirty minutes — thirty seconds. The cause was a hard disk failure on the primary playout machine. The backup system took over, but it took approximately thirty seconds to detect the failure and complete the handover. Thirty seconds is not an unusual failover window for broadcast automation platforms; the industry baseline for many commercial systems is five to thirty seconds.

The thirty seconds of dead air happened at 07:42, during the first advertising break after the morning news program. The break contained spots from a local supermarket, a regional auto dealer, and a county government public service announcement.

Here is what the next three weeks looked like.

The supermarket account manager called at 09:15 the same morning. By station records, this was not the first time the station had experienced an outage during this client's scheduled spots. The client invoked a make-good clause in their contract and requested both a replacement spot and a discount on the next booking cycle. The station's total revenue impact from that single client relationship was approximately 3,200 RMB in make-good airtime plus a 15% discount on the subsequent campaign, worth roughly 1,800 RMB. Total direct cost from one advertiser: approximately 5,000 RMB.

The auto dealer did not call. They did not renew. The station lost that account entirely at the next booking cycle. Direct revenue loss: approximately 28,000 RMB per year. Cause attributable to the outage: disputed. But the timing is not a coincidence.

The county government public service announcement presented a different problem. A government spot that does not air as scheduled creates a compliance documentation issue. The station had to provide written confirmation to the county government that the scheduled content was not aired and document the make-good delivery. This took three working days of administrative time.

The engineering post-mortem took four days of senior engineering time. The hard disk was replaced. The backup system's failover configuration was reviewed. Logging was improved. The engineering time cost was approximately 8,000 RMB in labor against a revenue-producing task count of zero.

The regulatory inquiry arrived two weeks later. The broadcasting regulator — responding to a listener complaint about the outage — requested a written explanation. Preparing the response required reviewing logs, drafting technical documentation, and getting sign-off from station management. Call it two senior staff days: approximately 3,000 RMB.

Total quantifiable cost of thirty seconds of dead air: approximately 45,000 RMB, plus an unknown portion of the lost auto dealer account. For a county-level station with annual advertising revenue in the 1.5 to 3 million RMB range, this is a meaningful event.

The Cost Cascade: Why Thirty Seconds Has a Long Tail

The thirty seconds itself is the smallest part of the problem. Dead air incidents generate cost cascades that extend for weeks or months, and the magnitude of each component is often independent of the duration of the outage.

Advertiser make-good costs are contractual obligations. Most broadcast advertising contracts contain clauses that require the station to provide replacement airtime when a scheduled spot does not air as contracted. The make-good may be provided in equivalent inventory, which means inventory that would otherwise be sold is now consumed by an obligation. Even when the replacement airtime is scheduled in unsold inventory, the opportunity cost is real.

The make-good conversation also damages the advertiser relationship in ways that do not show up in the incident accounting. Every conversation in which a client is told that their spot did not air is a conversation that makes the next renewal negotiation harder. We have seen stations where a pattern of outage-related make-goods over three years produced a systematic client base attrition that was never directly attributed to reliability issues in the station's own records.

Regulatory costs scale with the severity and visibility of the outage, not with its duration. A thirty-second outage at 07:42 on a weekday morning, during a commercial break, will generate more regulatory attention than a five-minute outage at 03:00 on a Sunday because the audience is larger and the commercial stakes are more visible. Chinese broadcasting regulations require continuous coverage during certain programming categories; an outage during a mandated broadcast window is a compliance incident regardless of duration.

Engineering labor costs are consistently underaccounted in post-mortems. The cost of an engineer investigating a failure is not just their hourly rate times the investigation hours. It includes the opportunity cost of whatever they were not doing during that time, the time of colleagues who are pulled into the post-mortem, and the downstream effect on other projects. A four-day post-mortem does not cost four engineer-days. It costs four engineer-days plus the context-switching overhead for every other project those engineers touched.

Audience attrition is the component that is hardest to quantify and easiest to ignore. Listeners who encounter dead air during a program they care about will, in some fraction of cases, change the habit of listening to that station. The fraction is small per incident. Over years of incidents it accumulates. Ratings data rarely captures this at the station level because the sample sizes are too small, but the pattern is consistent in the aggregate data we have seen across our customer base.

Brand damage is real at county and city level in ways that are not always obvious. In local broadcast markets, the station's reputation for reliability is a meaningful competitive differentiator. Listeners and advertisers talk to each other. A pattern of outages does not stay internal.

How KAVANA-DOG Changes the Economics

KAVANA-DOG is our watchdog process. Its fundamental function is to detect broadcast failure and execute handover before the failure becomes a listener experience. We have described the technical architecture in detail in other posts — the two-of-three failure detection logic, the pre-cached handover state, the sub-800-millisecond handover window — but the economics deserve their own treatment.

A station running KAVANA-DOG does not eliminate outages. Hardware fails, power fails, the playout machine has software bugs. What changes is the relationship between the technical event and the listener event. A hard disk failure on a DOG-monitored station produces a technical event — a failover, logged, alerted, requiring engineering follow-up — but not a listener event. There is no dead air. There is no make-good conversation. There is no regulatory inquiry triggered by a listener complaint.

Across our active station base, we have logging data on approximately 2,400 failover events over the past four years where DOG executed a handover before dead air was produced. These are events that, in the pre-DOG configuration of those stations, would have produced dead air in the range of five to thirty seconds each.

If we assume each of those events would have produced an average of fifteen seconds of dead air — conservative, given the industry baseline failover windows — and if we use the economic model from the county station case study to estimate average direct costs at approximately 5,000 to 15,000 RMB per incident (scaling down for shorter outages and smaller stations), the avoided cost across the customer base over four years is in the range of 12 million to 36 million RMB. That is a wide range, and we are being explicit that it is an estimate with significant uncertainty. The methodology is available if you want to scrutinize it.

What we are confident about is the direction. KAVANA-DOG's value is not in its engineering elegance — the two-of-three logic and the pre-cached state are clever but not unique. Its value is in converting technical failures into non-events from an economics standpoint. The engineering team still gets the alert, still does the post-mortem, still fixes the root cause. But the cascade of advertiser calls, make-good airtime, regulatory inquiries, and audience attrition does not start, because from the listener's perspective nothing happened.

The Alert System: Catching Failures Before They Cascade

Dead air that is caught quickly — within seconds — has substantially lower economic consequences than dead air that runs for minutes or hours before anyone notices. The economic cascade described above assumes somebody is paying attention when the incident starts. At 07:42 on a weekday morning, there is typically someone in the building. At 02:17 on a Wednesday night at a county-level station with no overnight staff, there may not be.

KAVANA-MGR provides the remote monitoring and alerting layer that extends the "someone is paying attention" window to 24 hours. When DOG detects and executes a failover, it simultaneously sends a status report through the reverse SSH tunnel to the monitoring endpoint — typically the broadcasting group's central facility. An engineer on call receives the alert and can assess whether the failover is handling the situation or whether human intervention is needed.

The alert system does not prevent the technical failure. It prevents the failure from running unchecked. A UPS failure at 02:17 that triggers a successful DOG failover and a monitoring alert produces a different economic outcome than the same failure running until the morning shift arrives at 06:00. In the first case, the engineering response happens at 02:17. In the second case, the engineering response happens at 06:00, after approximately three hours and forty-three minutes of — in the worst case — undetected dead air.

We have documented cases where the difference between monitored and unmonitored failures has been four to six hours of undetected dead air. At a music station, four hours of silence in the overnight window is a compliance incident and a listener experience incident that morning listeners will comment on. At a news station with overnight programming obligations, it is a more serious event.

The alert infrastructure also enables a different kind of response: remote diagnosis and often remote remediation. A playout software crash at 02:17 that triggers an alert will typically allow the on-call engineer to restart the process remotely over the reverse SSH tunnel, resolving the incident without dispatching anyone to the facility. This changes the on-call burden significantly — remote resolution within twenty minutes is very different from a physical callout that takes two hours minimum.

What the Numbers Say About Prevention vs. Recovery

Broadcast station managers and owners have two choices when it comes to dead air: invest in prevention or invest in recovery capacity. Recovery capacity means having fast processes for detecting and responding to dead air after it has occurred — protocols, on-call staff, make-good procedures that minimize advertiser damage. Prevention means investing in the infrastructure that stops dead air from occurring in the first place.

The numbers consistently favor prevention, for a reason that is obvious once stated: recovery costs scale with the duration and visibility of the outage, while prevention costs are fixed.

A monitoring and failover system that costs, say, 30,000 RMB to deploy and 6,000 RMB per year to support will prevent some number of outage events over its lifetime. If it prevents five outage events per year that would have produced average direct costs of 10,000 RMB each — which is a conservative estimate based on the case study above — the system pays for itself in roughly the first year and delivers ongoing positive return thereafter.

The comparison that matters is not "does the prevention infrastructure cost money" — it does — but "does it cost less than the expected cost of the outages it prevents." At stations with any meaningful advertising revenue and any pattern of technical incidents, the answer is almost always yes.

The harder argument to make is for the "it hasn't happened recently" station — a facility that has been lucky or has well-maintained hardware and hasn't had a significant outage in years. For that station, prevention spending is easier to defer because the recent cost of outages appears low. The problem is that broadcast hardware aging is not linear, and a station with aging playout infrastructure and aging UPS equipment is not accumulating good luck — it is accumulating risk. The 2019 incident described above happened at a station that had gone three years without a significant outage. The UPS had been degrading silently the entire time.

The Regulatory Pressure Is Not Getting Lighter

One dimension of dead air economics that is worth addressing directly is the regulatory trajectory. In China, broadcasting regulations around continuous coverage and content availability are enforced through a combination of regulatory inspections and complaint-driven inquiries. The tolerance for documented outages — particularly during mandated programming windows — has been decreasing, not increasing, over the past decade.

This matters for the cost calculation because regulatory consequences are not just one-time costs. A station with a documented history of reliability incidents is in a weaker position in license renewal conversations and in inspection contexts. The formal financial penalties for individual outages may be modest — a formal warning or a small fine — but the reputational and relational cost with the regulator compounds over time.

The research documentation we maintain at GitHub includes an analysis of Chinese broadcast regulatory enforcement patterns from 2018 to 2024 that is worth reading if you are making budget decisions about reliability infrastructure. The pattern is clear: enforcement frequency is up, tolerance for repeat incidents is down.

The Honest Limits of What Monitoring and Failover Can Do

We want to be clear about what our system does not solve.

Site-level failures — a building power cut that takes both primary and backup machines offline, or a flood that takes out the entire facility — are outside the scope of machine-level failover. Addressing site-level risk requires geographically separate backup infrastructure, which is a different architectural problem and a significantly higher cost discussion.

Content failures that exist on both machines simultaneously are also unaddressed by failover alone. If a corrupt audio file is in the playlist on both primary and backup, the failover does not help. Content integrity checking — which we implement through the wav9 audio layer — catches some of these cases, but not all. The wav9 layer validates that audio is present and at the expected level; it does not validate that the audio is the right content.

Human error remains the most common cause of KAVANA broadcast safetys at the stations we serve, and it is the hardest to address with technical infrastructure. A presenter who reads the wrong script live, an engineer who accidentally silences the wrong output, a production system that generates a malformed file — these are not problems that failover architecture solves. They require process, training, and organizational discipline that technical infrastructure can support but not replace.

What we can say honestly is that the incidents that technical infrastructure can prevent — hardware failures, software crashes, power events — represent a significant fraction of the total incident count at most stations we have analyzed, and that preventing those incidents produces measurable and significant economic benefit.

If you want to model the economics for your specific station situation — annual advertising revenue, advertising contract terms, incident history, current failover capability — we are happy to work through that with you. Reach us at international@kavanafm.com. We would rather you make the infrastructure decision with accurate numbers than with a general claim.

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.

About KAVANA

KAVANA is an AI-native radio playout system serving 500+ FM stations in China since 2005. We pioneer cloud-edge broadcasting with 1-second human takeover safety and three-tier AI review.

Website: www.kavanafm.com
GitHub: @kavanafm
Contact: contact@kavanafm.com

Why a Broadcast-Grade AI Radio Host Isn't Just TTS in a Fancy Wrapper

Qua Lekuch — Mon, 08 Jun 2026 03:06:37 +0000

Why a Broadcast-Grade AI Radio Host Isn't Just TTS in a Fancy Wrapper

By the KAVANA engineering team — June 2026

Every few months someone sends us a link to a demo video: a radio station that has replaced its human DJ with an AI voice. The demo sounds impressive. The voice is natural, the transitions are smooth, the audio quality is clean. The person sending the link usually adds: "this is what you should be building."

We have been building AI voice systems for broadcast since before most of those demo projects existed. Our honest response to the comparison is: the demo is doing text-to-speech. We are doing something different. This post explains what that difference actually is, why it matters technically, and what it costs to close the gap.

TTS Reads Sentences. A Broadcast Host Reads a Clock.

This is the most important distinction and the least obvious one if you have not worked in broadcast.

A text-to-speech system has one job: given a string of text, produce plausible audio that represents that text. The input is text. The output is audio. The system does not need to know what time it is, what segment of the program clock is active, whether this is a news break or a music sweep, whether the station is running long or short, or whether the previous segment ended cleanly or with an abrupt cut.

A broadcast host — human or AI — reads a clock. A broadcast program clock is a structured template that defines what kind of content plays when, in what order, with what timing constraints. A music format might specify: 6 minutes of music, 30-second liner, 4-minute music, 2-minute news, sponsor mention, music. The host's job is not just to read words. It is to fit within that clock, to adjust length based on where the clock actually is, to deliver content in a way that serves the function of each clock position, and to make the whole thing sound like it was planned even when it is being assembled live.

That requires different architecture at every level: the system that generates the script must know the clock position and target duration; the voice synthesis must be calibrated to the delivery style appropriate for that position; the output must be validated against the clock before it is committed to playout. A TTS wrapper around a language model can generate plausible-sounding radio content. It cannot read a clock without a significant amount of infrastructure around it.

The KAVANA AI Host system — which we call AI Three Gods internally, reflecting the three synthesis pipelines it orchestrates — is built around the clock as a first-class concept. Every synthesis request includes the clock position, the target duration range, and the adjacent content context. The output is validated against the clock before the file is written to the three-tier review system.

Prosody: The Gap Between Readable and Listenable

General-purpose TTS systems are optimized for intelligibility. The voice should be clear, the words should be understandable, the pacing should be natural for a human reading context — which typically means reading speed appropriate for a document being read silently, with prosody that sounds like a person reading aloud.

Broadcast prosody is different. It has been different for eighty years, through AM, FM, and digital, because the listening context is different. Radio listeners are not sitting quietly attending to the content. They are driving, working, cooking, exercising. Broadcast prosody is engineered to maintain attention in an environment with competing stimuli, to create energy appropriate to the daypart, to signal transitions between content types, and to create a sense of momentum that keeps the listener from reaching for the dial.

The specific prosodic markers differ by format and daypart. A morning drive host on a Top 40 station uses a delivery pattern that would sound completely wrong on a classical music station at 11 PM. A news reader's prosody is calibrated differently from a music host's. An emergency announcement has specific prosodic requirements that are essentially the opposite of normal broadcast style — slower, more measured, more explicit — because the communication priority shifts from maintaining attention to ensuring comprehension.

None of this is captured in a general-purpose TTS model. The models are trained on a distribution of human speech that includes broadcast content but is dominated by conversational and documentary speech. They produce plausible speech but not broadcast speech.

We address this through what we call scene-level voice design: for each of the nine broadcast scenes we support, we have tuned the synthesis parameters — speaking rate, pitch range, emphasis patterns, pause placement — specifically for that scene's listening context. We also expose these parameters to stations that want to adjust them for their specific format. This is not a simple slider. It is a configuration space that our engineers have spent considerable time calibrating against real broadcast output.

Nine Scenes, Nine Different Engineering Problems

Broadcast is not one thing. The engineering requirements for voice synthesis differ significantly across the nine scene types we support in KAVANA AI Host. Here is an honest account of what makes each one technically distinct.

Time call. This sounds like the simplest possible broadcast task: announce the time. It is actually one of the more demanding ones because the time call is a reference point in the listener's experience — it has to be precise to the second, it has to be delivered with a specific confidence and authority, and it has to work within a narrow duration window. A time call that runs 40% long is unusable. The synthesis must also handle the edge cases: top of the hour versus quarter hour versus half hour each carry different conventional phrasing in different broadcast cultures.

Station identification. Legal ID must appear within a specific time window relative to the top of the hour in most broadcast regulatory frameworks. The delivery has to be authoritative. The text is short and fixed, which means any prosody flaw is very audible. This is one of the scenes where voice cloning from the actual station voice talent produces significantly better results than a generic synthesized voice.

News segment. Multiple story items, each with different subject matter and emotional register. The host needs to transition between a story about a local government budget and a story about a regional flood without inappropriate affect carryover. The pacing needs to allow comprehension without feeling slow. Duration management is critical — if stories are running long, the synthesis needs to know and adjust accordingly.

Weather segment. Similar to news but with a more constrained vocabulary and a strong listener expectation about format. The challenge is making a structured data dump — temperature, precipitation probability, wind speed — sound like natural speech rather than a recited list.

Music host liner. This is where broadcast AI voices most often fail. The music liner needs energy, personality, and timing relative to the music it brackets. It needs to land on a specific beat, which means the synthesis duration has to be predictable to within a fraction of a second. General TTS produces variable-length audio with variable prosody; music host liners require consistent duration and calibrated energy.

Sponsor mention. Regulatory and ethical requirements vary by jurisdiction. The synthesized voice must be clearly identified as automated in any jurisdiction that requires this. The content must match the approved copy exactly, with no paraphrasing — this is both a legal requirement and a contractual one.

Traffic and travel. High information density, rapidly changing underlying data, strict duration constraints. The synthesis must handle alphanumeric strings (road designations, junction numbers) correctly. Different broadcast cultures have different conventions for how traffic information is phrased.

Cultural and community content. For the regional and community stations that make up a large part of our customer base, this includes local event announcements, community notices, and format-specific content that may be in a minority language or dialect. This is where generic TTS models fail most obviously: they were not trained on this content and the errors are immediately audible to local listeners.

Emergency announcement. Different delivery requirements, potentially different voice, different prosody. In some regulatory frameworks, emergency content must be identifiably different from normal programming. The synthesis pipeline has a separate configuration for emergency content that deliberately breaks from the station's normal voice characteristics to signal the change in information type.

What We Actually Use Under the Hood, and Why

We use multiple synthesis backends, and the choice of which backend handles which scene is not arbitrary.

Alibaba Cloud CosyVoice 3 is our primary cloud synthesis backend. It produces high-quality Chinese-language broadcast speech with good prosody control and reliable duration prediction. We use it for scenes where latency is not critical (content can be synthesized in advance) and where the cloud round-trip is acceptable.

For local GPU inference, we use our OmniVoice pipeline — our internal name for the production instance of CosyVoice 2 that runs on KAVANA cloud-edge at the station or at a regional hub. Local inference eliminates the cloud latency and the data transmission, which matters for content that contains potentially sensitive local information and for stations with poor internet connectivity. The AI listening interface gives stations a way to preview and verify synthesized content before it goes to playout.

MiniMax is our third pipeline, used primarily for voice cloning use cases where the station has provided voice samples and wants synthesis in a cloned voice. MiniMax's multi-speaker synthesis quality for cloned voices is, in our testing, currently ahead of the alternatives for the languages we support.

We do not use ElevenLabs, Azure Speech, OpenAI TTS, Bark, or Coqui in our production pipeline, though we have evaluated all of them. The reasons differ by product. ElevenLabs produces excellent voice quality but its architecture is optimized for on-demand cloud synthesis at the API level, not for the tight integration with a broadcast clock that we need, and its pricing structure is not viable for the station volumes we serve. Azure Speech has good API design and reliable SLAs but its Chinese-language voice quality for broadcast prosody is behind the local models. OpenAI TTS is designed for conversational assistant use cases and shows it in the prosody. Bark and Coqui are interesting research systems; production stability for broadcast is not where they need to be.

The honest comparison is that ElevenLabs is better than us for use cases where you want a high-quality synthesized voice for a one-off production. We are better than ElevenLabs for use cases where you need a synthesis system that understands broadcast clock structure, runs locally, integrates with a playout system, and is priced for a county radio station's budget rather than an enterprise content production team.

Voice Cloning: Where the Ethical and Legal Lines Actually Are

Voice cloning is technically feasible. The question of whether it is appropriate in a given context is more complicated, and we have spent considerable internal time on this.

The straightforward case: a station wants to synthesize content in the voice of a professional voice actor who has been hired specifically for this purpose and has contractually agreed to it. This is a standard commercial transaction with clear legal footing. We support it.

The more complicated case: a station wants to clone the voice of an existing on-air personality — a human DJ or news reader who has been working at the station for years and whose voice is associated with the station's identity. The legal status of this varies significantly by jurisdiction. In most frameworks, the on-air personality owns their voice, and using it without consent for AI synthesis purposes is a rights violation regardless of whether the station "owns" the recordings that could be used for training. The employment contract may or may not address this — most broadcast employment contracts predate voice cloning as a practical technology and are silent on the question.

We do not enable voice cloning of identified individuals in our system without a documented consent chain. This is not purely an ethical position — it is also a legal risk position. A station that clones an employee's voice without clear authorization is exposed to claims that are novel but not clearly going to fail. We are not going to create that exposure for our customers.

The additional complication is AI disclosure. Several jurisdictions now require that AI-synthesized broadcast content be disclosed as such to listeners. The regulatory landscape here is moving fast and is inconsistent across markets. We have built disclosure capabilities into the system — the ability to insert a standard disclosure announcement at configurable intervals — but the specific requirements are the station's responsibility to understand and configure for their jurisdiction.

We have published our position on voice ethics and the technical architecture of consent verification as part of our technical documentation. We think the broadcast industry needs clearer standards here and we are willing to participate in developing them.

The Cost Structure Is Genuinely Different

We want to address this directly because it comes up in every evaluation conversation.

ElevenLabs, Azure Speech, and similar cloud TTS services charge per character or per audio hour. At low volumes this is fine. At broadcast production volumes — a station producing multiple hours of synthesized content per day across multiple voices and multiple segments — the per-unit cost adds up to an ongoing operational expense that is a meaningful line item.

Our pricing model is different. The software license covers the synthesis pipeline. The incremental cost for synthesis is the cost of running local GPU inference (electricity, amortized hardware cost) plus any cloud API costs for the cloud synthesis pipelines you choose to use. For a station that runs primarily local inference, the marginal cost of synthesis approaches zero after the hardware is paid for.

The upfront cost is higher. The KAVANA cloud-edge required for local inference is a capital purchase that cloud synthesis does not require. Whether the total cost of ownership is better or worse depends on the station's volume, its internet reliability, its data residency requirements, and its access to capital for hardware purchase versus ongoing OpEx budget for cloud services.

We do not claim to be cheaper in every scenario. We claim that for stations with high production volumes, local data residency requirements, or budget structures that favor capital expenditure over ongoing subscription costs, our cost model is often significantly better. We encourage stations evaluating us to model their specific situation rather than accepting a general claim.

What This Actually Sounds Like

The fair question at the end of all of this is: does the output actually sound good?

We have samples on the KAVANA listening interface that represent production output across several of our broadcast scene types. They are real output from the production system, not curated demos. We think the quality for Chinese-language broadcast content is competitive with the best available alternatives. For other languages, the quality depends on the underlying synthesis model; our pipeline can integrate with local language models, but we do not ship voice models for languages outside our current customer base.

The honest answer is: listen for yourself. The samples are there. If you are evaluating AI synthesis for your station, listen to them the way your listeners will — in the car, with the window down, at the normal listening volume — not through studio monitors in a quiet room. Broadcast audio is designed for one context. It should be judged in that context.

Reach us at international@kavanafm.com with questions about specific use cases, languages, or technical integration requirements. We try to give direct answers rather than directing you to a sales process.

About KAVANA

KAVANA is an AI-native radio playout system serving 500+ FM stations in China since 2005. We pioneer cloud-edge broadcasting with 1-second human takeover safety and three-tier AI review.

Website: www.kavanafm.com
GitHub: @kavanafm
Contact: contact@kavanafm.com

What is a radio playout system? A 2026 buyer's guide for station engineers and program directors

Qua Lekuch — Mon, 08 Jun 2026 03:05:05 +0000

What is a radio playout system? A 2026 buyer's guide for station engineers and program directors

Reading time: ~18 minutes. Audience: station engineers, program directors, and technology advisors who are evaluating or replacing broadcast automation software.

1. What is a radio playout system — and how the definition changed over 20 years

A radio playout system is the software layer that sits between your content library and your transmitter. It decides what plays, when it plays, at what loudness level, and what happens when something goes wrong. That sounds simple, but the operational consequences of getting it wrong are immediate and public: dead air, mis-timed commercials, regulatory compliance violations, or — in countries with emergency broadcast mandates — a failure to interrupt programming when the regulator demands it.

The term itself has shifted meaning across three generations of technology.

Generation 1 (1970s–1990s): tape and cart machines. Playout was a physical act. A cart machine loaded with a jingle, a reel-to-reel carrying the overnight drama, a stack of vinyl for the morning show. The "system" was the traffic log printed the night before and the human operator following it. Reliability depended entirely on staff discipline and mechanical maintenance. Cue marks, silence sensors, and switchers existed, but the integration between scheduling and playout was loose at best — often a printed log and a clipboard.

Generation 2 (1990s–2010s): digital audio workstations and on-premise broadcast automation. CD carousels gave way to hard disk storage. Purpose-built broadcast automation platforms appeared: Windows-based servers holding tens of thousands of audio files, proprietary scheduling engines, hardware playout cards connected to the transmission chain. The key architectural advance was the separation of the content database from the scheduling engine from the physical output — a three-tier model that is still the correct architecture today. Reliability improved dramatically, but these systems were expensive, required local IT infrastructure, and the scheduling logic was often opaque and difficult to modify.

Generation 3 (2015–present): hybrid compute, AI integration, cloud-aware. The current generation of playout software treats the audio file as one of many possible content sources. AI-generated voice segments, real-time traffic and weather data synthesized on demand, live streaming ingest from remote contributors, emergency alert intercept from regulatory agencies — all of these are first-class inputs alongside pre-recorded audio. The scheduling engine needs to be aware of content validity windows, regulatory compliance categories, and the difference between a segment that can be deferred versus one that must air at a precise clock position.

A complete modern radio playout system is therefore not a single application. It is a stack of coordinated subsystems, each with a distinct engineering responsibility. The rest of this guide examines what those subsystems are, how to evaluate them, and what realistic deployment looks like in 2026.

2. How playout relates to scheduling, monitoring, AI host, and compliance

These four concerns are often conflated in vendor marketing. In practice, they have separate failure modes, separate regulatory implications, and separate staffing requirements. Understanding the boundaries helps you write a better RFP and ask better questions during demos.

Scheduling is the upstream layer. It answers: what content should play during this hour? Scheduling systems manage traffic logs (paid commercial spots), music rotation (format rules, dayparting, artist separation), news blocks (fixed clock positions), and regulatory mandatory content (local news quotas, language broadcast ratios in some jurisdictions). A scheduling system produces a playlist or log that the playout system consumes. The two are often sold as a bundle but should be evaluated independently — the scheduling engine has direct contact with your commercial billing system, your music licensing database, and your regulatory compliance records.

Monitoring is the downstream layer. It watches what actually went to air and compares it against what was supposed to go to air. Good monitoring captures the output audio stream, timestamps every item played, logs every deviation from the scheduled log, and generates compliance reports for regulators. In countries with content quota requirements, this log is not optional — it is the evidence you submit to demonstrate compliance.

AI host integration changes the nature of the content itself. When an AI voice talent reads a traffic update synthesized from real-time data, the playout system is not just playing a file — it is triggering a generation pipeline, receiving an audio artifact, ingesting it, and scheduling it into the clock without human intervention. The engineering requirement here is latency tolerance: the playout system must understand how long content generation takes and plan the clock accordingly. A system that assumes all content is pre-recorded will not handle this correctly.

Compliance in broadcast is multi-layered. Loudness compliance (EBU R128, ATSC A/85 depending on jurisdiction) is a signal-level concern. Content compliance (watershed rules, political advertising rules, language quotas) is a metadata and logging concern. Emergency compliance (EAS in the US, national alert systems in other countries) is an intercept-and-override concern that requires a dedicated hardware or software path that cannot be blocked by normal playout logic. A playout system that treats compliance as an afterthought creates liability for the license holder.

The correct mental model: scheduling is your production plan, playout is your manufacturing floor, monitoring is your quality control audit, and compliance is your regulatory interface. All four must work together, but they should not be architecturally fused to the point where a failure in one takes down the others.

3. Core modules of a complete playout stack

A production-ready broadcast automation stack in 2026 typically consists of five functional modules. Some vendors bundle all five into one application; others sell them as separate licensed components. The bundled approach reduces integration work but creates a single point of failure and makes it harder to upgrade individual components.

3.1 Playout master (the playback engine)

This is the component most people mean when they say "playout system." It manages the audio output queue, handles crossfades and transitions, executes start/end commands on external hardware (satellite receivers, live input switchers), and maintains the real-time clock position of the broadcast. Key engineering requirements:

Sub-100ms audio transition precision for live-to-file switches
Graceful handling of missing or corrupt audio files (skip, substitute, alert — never silence)
Stable operation under sustained load (a 24/7 automation system should run for weeks without restart)
Clear logging of every playout event with timestamps accurate to the audio sample level

KAVANA's playout master is MGR, designed for unattended overnight operation and multi-channel simultaneous playout at county-level and above stations.

3.2 Scheduling backend

The scheduling backend holds the content catalog, the traffic log, the music rotation rules, and the clock templates for each daypart. It generates the playout queue in advance (typically 24–48 hours) and pushes updates to the playout master in real time when changes occur. Engineering requirements:

Reliable sync to the playout master even over unreliable network links
Conflict detection: the system should refuse to schedule a commercial spot that conflicts with a regulatory content block, not silently drop it
Version history: you need to reconstruct exactly what was scheduled on any given day for regulatory audit purposes

KAVANA's scheduling backend is ADV, which manages daypart templates and integrates directly with AI content generation pipelines.

3.3 Safety guardian (watchdog and dead-air detector)

This is the module that saves your license when everything else fails. It runs independently of the playout master, monitors the audio output, and takes corrective action if it detects silence, a level below threshold, a frozen stream, or a process crash. The safety guardian should be architecturally isolated from the playout master — if the playout master crashes, the safety guardian must still be able to play fallback content. Engineering requirements:

Independence: different process, ideally different hardware path
Fast response: silence detection and fallback injection within 2–3 seconds
Configurable response hierarchy: local fallback audio → network fallback stream → tone → transmitter mute (depending on regulatory requirement)
Alert routing: page/email/SMS the engineer on duty within seconds, not minutes

KAVANA's safety guardian is DOG, which has been in production at over a dozen stations handling overnight unattended broadcast.

3.4 AI radio host

This is the newest module category and the one with the most variation in maturity. An AI radio host is not just text-to-speech. It is a pipeline that: (a) determines what to say based on context (time of day, what just played, current news, weather, traffic), (b) generates a script using a large language model, (c) renders audio using a voice synthesis engine, and (d) delivers the audio artifact to the playout master with enough lead time to schedule it correctly. The weak links in most current implementations are (a) — the context-awareness is shallow — and (d) — the latency from trigger to ready-audio is often longer than the playout system expects.

KAVANA's AI host module is at kavanafm.com/en/ai, integrating real-time data sources with on-premise voice synthesis to avoid per-character cloud TTS billing at scale.

3.5 Compliance and security layer

This is the module that most station engineers underestimate until they face a regulatory audit or a cyberattack. It covers: three-tier content review (flagging AI-generated content for human approval before air), emergency alert intercept and mandatory relay, loudness normalization on the output chain, access control and audit logging for all operator actions, and network security (broadcast systems have historically been connected to corporate networks in ways that would make a security auditor uncomfortable). KAVANA's compliance and security layer is documented at kavanafm.com/en/aiSanShen.

The production toolbox — audio processing utilities, batch normalization, metadata management — lives at kavanafm.com/en/aiUtils and is documented further in the engineering blog.

4. How to evaluate a radio playout system: a practical framework

Most vendor demos show the system working perfectly. Your job is to find out what happens when it does not. Here is a structured evaluation framework that goes beyond the demo.

4.1 Technical KPIs to measure, not just ask about

Do not accept vendor claims about reliability — measure them. Ask for access to a staging environment and run the following tests:

Silence latency: trigger a silence condition (stop the audio source) and measure how long before the safety guardian fires and fallback audio begins. Anything over five seconds is too slow for most regulatory environments.
Failover path isolation: kill the playout master process and verify the safety guardian operates independently. If the safety guardian is in the same process, you do not have real redundancy.
Schedule sync under load: push a large schedule update (say, replacing all commercial spots in the next four hours) while the system is live and measure how long until the playout master reflects the change.
Corrupt file handling: inject a zero-byte audio file into the schedule and watch what the system does. Does it skip gracefully? Log the error? Alert the engineer? Or does it loop on the error and miss the next scheduled item?
Long-run stability: ask for the uptime logs of a production installation running the same software version. A system that requires weekly restarts is not production-grade for unattended overnight broadcast.

4.2 Engineering team questions

The software is only part of the picture. Ask:

Who wrote the core playout engine? Is it maintained in-house or is the vendor reselling a third-party component?
What is the patch cycle for security updates? For a system connected to a transmitter, an unpatched vulnerability is a regulatory and safety risk.
What does the vendor's support SLA look like at 3am on a Sunday? A broadcast outage does not wait for business hours.
What is the migration path if you want to replace one module (say, upgrade the AI host) without replacing the entire stack?

4.3 Regulatory compliance

This varies significantly by jurisdiction, but common requirements include:

Emergency alert system integration (EAS in the US; equivalent national systems elsewhere)
Content logging with tamper-evident audit trails
Loudness normalization to jurisdiction-specific standards
Local content quotas (some jurisdictions require a minimum percentage of locally produced content)
Political advertising segregation and disclosure

Ask vendors to show you how each of these is implemented, not just claimed. Ask for the configuration interface, not the marketing slide.

4.4 Post-sales and total cost of ownership

A radio scheduling system purchase is not a one-time transaction. Budget realistically for:

Annual software maintenance and support fees (typically 15–25% of license cost for enterprise broadcast systems)
Hardware refresh cycles (playout servers have a practical life of 5–7 years in broadcast environments)
Staff training and onboarding when you hire new engineers
Integration costs when you connect to new systems (new traffic system, new music licensing database, new emergency alert provider)
Regulatory compliance updates when rules change

The vendors who are honest about these costs are usually the ones whose systems hold up over time. Vendors who minimize TCO in the sales process often have support organizations that are not designed for the ongoing relationship.

5. The vendor landscape in 2026

The playout software market in 2026 is more fragmented than it appears from the outside. There are four broad categories of vendor, each with distinct tradeoffs.

Legacy on-premise specialists. These are vendors who built their platforms in the late 1990s and 2000s for large-market commercial radio and television. Their platforms are stable, well-integrated with industry-standard traffic systems, and supported by large sales and support organizations. The downsides: the core architecture is old, AI integration is often bolted on rather than native, and pricing reflects a market that expected large capital budgets. Many of these platforms require hardware from the same vendor, creating lock-in that becomes expensive over time. They are reasonable choices for large commercial stations with established IT departments and no immediate need for AI host integration.

US and European cloud SaaS platforms. A newer category that emerged in the 2010s, these platforms offer browser-based scheduling and cloud-hosted playout. The pitch is lower upfront cost and easier remote management. The operational reality is that a cloud-hosted playout system introduces a network dependency into your transmission chain — if your internet connection degrades, your broadcast degrades. Some vendors address this with local caching agents; others do not. Pricing models based on per-stream or per-station fees can become expensive at scale. Regulatory compliance for non-US jurisdictions is often incomplete.

Chinese broadcast-grade platforms. China has developed a parallel ecosystem of broadcast automation software, driven by the regulatory requirements of state and regional broadcasters. These platforms are built for the specific compliance requirements of Chinese regulators (content review workflows, emergency relay integration with national alert systems, audit logging formats). They are generally not designed for export or for regulatory environments outside China. Engineering documentation in non-Chinese languages is limited.

Emerging hybrid platforms. This is the category KAVANA occupies. These are platforms built from the ground up in the 2020s, designed with AI integration as a native concern rather than an afterthought, and intended to operate in environments where the network is unreliable, the IT team is small, and the regulatory requirements are specific to a non-US jurisdiction. The tradeoff is that these platforms have shorter track records in very large deployments, and the ecosystem of third-party integrations (music licensing systems, traffic systems, ratings services) is narrower.

There is no category that is right for every station. The framework in section 4 will help you identify which tradeoffs are acceptable for your specific operational context.

6. Deployment models: on-premise, cloud, and hybrid

The deployment model decision is more consequential than most buyers realize, because changing it later is expensive.

On-premise deployment means the playout server, scheduling database, and safety guardian all run on hardware at your facility. The audio output goes directly to your transmission chain with no internet hop. Advantages: lowest latency, no network dependency for core playout, full control over the security perimeter, no ongoing cloud fees. Disadvantages: you own the hardware refresh cycle, you need local IT capacity to maintain the servers, and remote management requires a VPN or similar infrastructure.

For stations in markets with unreliable internet infrastructure, on-premise is not a preference — it is a requirement. A playout system that depends on a cloud connection cannot provide the uptime guarantee that a broadcast license demands.

Cloud deployment means the playout engine and scheduling database run in a data center, and your facility has a client application that streams the output or retrieves the audio queue. Advantages: no local server to maintain, easier multi-site management, vendor handles the hardware refresh. Disadvantages: your transmission chain now depends on your internet connection and the vendor's data center uptime. A 99.9% SLA sounds good until you realize it means 8.7 hours of potential downtime per year — more than enough to trigger a regulatory complaint.

Hybrid deployment is the model that most mature stations are moving toward in 2026. The core playout engine and safety guardian run on-premise. The scheduling backend, content library, and AI generation pipeline run in the cloud or on a local high-performance server with cloud synchronization. Remote management and monitoring are cloud-hosted. This gives you the transmission reliability of on-premise with the management convenience of cloud, at the cost of more complex architecture.

The KAVANA architecture is built for hybrid deployment: the DOG safety guardian and MGR playout master run on-premise; the ADV scheduling backend and AI pipelines can run locally or connect to cloud services depending on the station's infrastructure.

7. Selecting a system for different station scales

The correct radio playout system for a 50-watt county AM station is not the same as the correct system for a provincial FM network with 20 relay transmitters. The selection criteria shift meaningfully across scale.

County-level and small-market stations typically have two to four staff members who cover engineering, production, and operations. The playout system must be operable by non-specialists. Remote management capability is essential — someone needs to be able to restart a stuck process or push an emergency update from home at 2am. The safety guardian must be highly automated because there is no engineer on-site overnight. Cost is a primary constraint. AI host integration is often the most compelling feature because it allows a small team to maintain 24/7 programming quality without the cost of round-the-clock staffing.

Key requirements: simple UI, stable unattended operation, automated safety response, remote management, low total cost of ownership.

Metro and regional stations have larger engineering teams and more complex programming. The scheduling system needs to handle multiple dayparts with different music formats, complex commercial traffic logs, and potentially multiple simultaneous streams (main channel plus HD subchannels or streaming). Integration with existing traffic and billing systems is a significant consideration — a new broadcast automation platform that cannot connect to your existing traffic system means double-entry of commercial data. Regulatory compliance logging is more visible at this scale because regulatory audits are more frequent.

Key requirements: traffic system integration, multi-channel capability, compliance audit logging, scalable content library.

Provincial and national networks face a different class of problem. They are managing content distribution across dozens or hundreds of transmitter sites, coordinating live program feeds with local content insertion windows, and maintaining compliance across multiple regulatory jurisdictions. The playout system at this scale is less about individual station operation and more about network orchestration — scheduling which programs air on which transmitters at which times, managing the handoff between network feed and local programming, and monitoring the entire network from a central operations center.

Key requirements: network-wide scheduling, centralized monitoring, failover coordination across sites, integration with satellite or IP distribution infrastructure.

International broadcast operations add language and regulatory complexity. A station broadcasting in multiple languages needs scheduling logic that handles language-specific content quotas, voice talent management across languages, and regulatory compliance frameworks that differ by target country. AI host integration is particularly valuable here because generating presenter content in multiple languages with consistent brand voice is operationally difficult with human talent alone.

8. 2026 trends shaping radio playout system selection

These are the developments that are actively changing buyer requirements in 2026. They are worth understanding because they affect both what you should buy now and what your current vendor's roadmap needs to include.

AI host integration moving from experiment to production requirement. Two years ago, an AI radio host was a novelty. In 2026, stations that have deployed AI-generated presenter content in overnight and weekend slots are reporting meaningful cost reduction and, in some cases, better audience retention than generic music-only automation. The operational requirement this creates for playout software is non-trivial: the system needs to trigger content generation, manage generation latency, handle generation failures gracefully, and integrate the AI-generated audio into the live playout queue without human intervention. Systems that were not designed with this workflow in mind are being patched to add it — and the patches show.

Hybrid compute as the default architecture. The clean separation between "cloud software" and "on-premise software" is dissolving. In 2026, a realistic production architecture has the playout master and safety guardian on-premise, the scheduling and content management in a local server with cloud sync, and the AI generation pipeline running on a local GPU server to avoid per-character TTS costs at scale. This is not theoretical — it is the architecture that cost-conscious station engineers are actually deploying. Vendors whose platforms cannot support this hybrid model are losing evaluations.

Audio firewall formats and content authentication. As AI-generated audio becomes easier to produce, the risk of malicious audio injection into broadcast systems increases. Regulatory bodies in several jurisdictions are beginning to ask questions about how stations verify that audio reaching the transmitter is authorized content. Audio firewall formats — metadata schemes that authenticate content origin and verify that it has passed review — are moving from academic discussion to active development. Stations evaluating broadcast automation platforms in 2026 should ask vendors about their roadmap for content authentication.

Regulator readiness for AI-generated content. Most broadcast regulators were not writing their rules with AI-generated content in mind. In 2026, this is changing. Some jurisdictions are requiring disclosure when AI-generated content airs during news programming. Others are extending existing content review requirements to AI-generated segments. The three-tier content review workflow — automated flag, human review, release to air — is becoming a compliance requirement in some markets rather than just a best practice. Stations evaluating AI host integration need to understand not just what the technology can do, but what the regulatory framework requires.

Station consolidation driving multi-site management requirements. In many markets, small and medium stations are being acquired and operated as groups. This changes the requirements for radio scheduling systems significantly: a group operator needs centralized scheduling for shared network content, with local insertion points for each station's mandatory local content. This is an architectural requirement that affects how content databases, scheduling templates, and playout masters are organized. Group operators evaluating new platforms need to ask specifically about multi-site scheduling with local override — not just whether it is possible, but how it is implemented.

9. Common buyer mistakes

These are the errors that experienced broadcast engineers see repeatedly when stations evaluate and deploy playout systems. They are worth cataloging because the consequences of each are both predictable and expensive.

Treating SaaS pricing as equivalent to on-premise pricing. A SaaS playout platform priced at $X per month looks cheaper than an on-premise system priced at $Y upfront — until you model the cost over five years and add the infrastructure you need to make the internet-dependent SaaS platform reliable enough for broadcast. Do the TCO calculation with realistic assumptions about network reliability, support costs, and the cost of downtime.

Skipping the three-tier content review workflow. Stations deploying AI-generated content without a human review step before air are creating regulatory liability. The argument that "the AI is accurate enough" does not survive an incident — and incidents happen. A three-tier review workflow (AI generation → editor review → playout authorization) adds latency but is the only defensible operational model for AI-generated news and information content.

Underestimating the integration cost. The playout system does not exist in isolation. It connects to your traffic system, your music licensing database, your emergency alert system, your monitoring and logging infrastructure, and increasingly your AI generation pipeline. Integration costs are routinely underestimated because they are not visible in the vendor demo. Ask for a list of supported integrations and a realistic estimate of integration cost for your specific environment.

Ignoring TCO over three years. Software license cost at year zero is the least important number in the evaluation. Annual support and maintenance fees, hardware refresh, training when staff turns over, regulatory compliance updates — these accumulate. A platform that looks affordable at purchase often looks expensive by year three. Get multi-year cost estimates in writing.

Underestimating the regulatory burden of AI content. Regulators are paying attention to AI-generated broadcast content. The station's license holder — not the software vendor — is responsible for what goes to air. Deploying an AI host without understanding the regulatory framework in your jurisdiction is a license risk. Before deployment, consult with your regulatory counsel and understand what disclosure, logging, and review requirements apply.

Selecting a platform without asking about the failure mode. Every system fails eventually. The question is not whether your radio playout system will experience a failure, but whether the failure mode is safe. Ask vendors specifically: what happens when the scheduling server loses network connectivity? What happens when the audio generation pipeline is overloaded and cannot deliver content on time? What happens when the safety guardian detects silence at 3am? If the vendor cannot answer these questions precisely and specifically, the failure modes have not been designed — they are accidents waiting to happen.

Buying based on features rather than operational fit. A system with 200 features that requires three engineers to operate is not a good fit for a two-person county station. A system with 50 features that runs stably for months without intervention might be exactly right. Evaluate against your operational reality, not against a feature checklist.

10. How to get started — the KAVANA perspective

KAVANA is a broadcast automation platform built by a team that operates radio stations, not just sells software to them. The development context matters: every feature in the platform has been tested in production environments where an outage has regulatory and reputational consequences for the people who wrote the code.

The platform is designed around the hybrid on-premise/cloud architecture described in section 6. The core playout and safety components run locally; AI generation and cloud management are available as extensions, not requirements. This reflects the operational reality of many stations in markets where internet reliability is not guaranteed and where the IT team is small.

The five core components — MGR (playout master), ADV (scheduling backend), DOG (safety guardian), AI host, and compliance layer — can be deployed as an integrated stack or selectively integrated into an existing infrastructure. The AI production toolbox supports production workflows independently of the playout stack.

The platform's source architecture is open to inspection at github.com/kavanafm. For stations that require auditability of the software running their transmission chain — which is a reasonable requirement — this is a meaningful differentiator.

For stations beginning an evaluation:

Start with a clear inventory of what you have and what is failing. The most common starting points are: (a) overnight automation that is unreliable and requires manual intervention, (b) AI host integration that a previous vendor promised and did not deliver, (c) regulatory compliance logging that is inadequate for audit purposes, and (d) a legacy system that has reached end-of-life and is no longer receiving security updates.

Each of these entry points leads to a different evaluation path. An unreliable overnight automation problem is primarily a safety guardian and playout stability question. An AI host integration gap is primarily an architecture and latency question. A compliance logging gap is primarily a data capture and export question. A legacy system replacement is primarily an integration and migration question.

Identify your actual failure before evaluating solutions. Vendors who cannot tell you which of their modules addresses your specific failure mode are selling you a product, not solving your problem.

For stations already using broadcast automation and considering an upgrade:

The right time to evaluate alternatives is before you need to, not during a crisis. Build an evaluation timeline that gives you 6–12 months from initial evaluation to production deployment. Include time for: integration testing with your existing traffic and music systems, staff training, parallel operation (running old and new systems simultaneously), regulatory review of the new system's compliance capabilities, and a realistic cutover plan that does not involve a live broadcast.

The broadcast automation market in 2026 has more viable options than it did five years ago. The AI integration capabilities that were theoretical in 2021 are in production in 2026. The hybrid compute architecture that required custom engineering is now available as a supported deployment model. Stations that have delayed an upgrade because the options were not good enough should re-evaluate.

Additional technical detail on specific engineering topics — loudness normalization, overnight automation design, emergency broadcast integration, audio codec pipelines — is available in the KAVANA engineering blog.

This guide reflects operational experience and publicly available technical information as of 2026. Regulatory requirements vary by jurisdiction; consult your regulatory counsel before making compliance-related system decisions. KAVANA does not receive compensation from any vendor mentioned in this guide.\n\n---\n\n*Originally published at https://www.kavanafm.com/blog/en/what-is-radio-playout-system-2026.html*\n\n\n---\n\n**About KAVANA**\n\nKAVANA is an AI-native radio playout system serving 500+ FM stations in China since 2005. We pioneer cloud-edge broadcasting with 1-second human takeover safety and three-tier AI review.\n\n- Website: www.kavanafm.com\n- GitHub: @kavanafm\n- Contact: contact@kavanafm.com