Plan an offline voice that knows when to stop

Plan what the visitor hears after pressing Stop

A museum visitor chooses a short description of a mineral specimen, then taps another exhibit before the first sentence ends. The screen changes immediately, but the old narration keeps playing for several seconds. The second description starts over it. Both voices may sound excellent in isolation; together they make the kiosk hard to use. An offline speech system needs a plan for the moment its output is no longer wanted.

Gradium’s November 5 Phonon article is a closer look at a release the authors say they opened two weeks earlier. It describes text-to-speech models designed to run locally and a runtime named ptts. The English 31M model has an Apache 2.0 license; the 40M family, including multilingual options, uses CC BY-NC 4.0, with separate commercial arrangements discussed by the developer. “Open weights” therefore does not mean that every checkpoint has the same permitted uses.

That makes Phonon worth examining for a kiosk, but it does not settle the production decisions. The fictional museum example below is a design exercise, not a deployment report or a claim of hands-on testing. The kiosk offers approved descriptions through a selected synthetic voice, without cloning anyone. Its content is fixed enough that the museum can listen to every passage before visitors do.

Treat the spoken experience as a small application with its own states: preparing, ready, playing, paused, stopped, and unavailable. Decide what the visitor can do in each one. An attractive voice is one part of that experience. Pronunciation, interruption, local installation, and the ability to follow the same material silently will determine whether the kiosk is useful when the gallery fills up.

Source: Gradium: A Closer Look at Phonon TTS ↗ · Gradium: phonon-31m-en model card ↗ · Hugging Face Transformers: Gradium Phonon TTS documentation ↗

Make the offline promise specific

Write down the exact situation the installation must survive. “Offline” might mean the kiosk starts and speaks after its network cable is disconnected, including after a power outage. It might instead mean only that speech continues once an online page has finished downloading its assets. Those are different requirements. For the museum, choose the first: a fresh restart in the gallery must expose the approved content and usable speech controls without contacting a remote service.

List everything needed to satisfy that promise: application files, model files, a voice, the runtime, the content, and any pronunciation rules. Keep the approved versions together in a release manifest. A model already stored on disk will not help if the page still tries to fetch its voice or an essential script from elsewhere. Give installation an explicit preparation step and a visible check that the required local files exist before the kiosk becomes available to visitors.

The model card lists the English model’s quantized weights at 64.5 MB. That file size is not a complete memory or storage budget for the application. Account separately for runtime memory, audio buffering, the operating system, local content, and cached audio. Hardware support is also a reason to investigate a device, rather than proof that a particular configuration meets your needs. The runtime and reference implementation can use different paths, so record which one the installation actually packages.

Test the chosen machine in the condition staff will leave it in: the intended operating system, browser or app, audio output, and background tasks. Measure startup after a restart, the wait after selecting an exhibit, and whether playback stays smooth across a long session. Record the conditions with each result. If the machine struggles, the next decision could be to pre-render approved audio, shorten the immediate introduction, or choose another device. None of those decisions requires promising performance that a model announcement cannot establish for your kiosk.

Give each passage a spoken edition

A display label and a spoken passage serve related purposes, but they need not be identical strings. A label can use abbreviations, a catalog number, or compact measurements that a reader can inspect at leisure. Speech unfolds once, in order. Keep the museum’s approved display text as one content field and its approved spoken text as another, linked to the same exhibit identifier and editorial revision.

Take a hypothetical label containing “Specimen B-204, 3.5 cm.” Decide whether the identifier should sound like a catalog code or an ordinary number. The spoken edition might say “Specimen B, two zero four” and “three point five centimeters.” A visitor should be able to match those words to the screen. Do not expand an abbreviation by guessing what the curator meant. Ask the content owner, record the expansion, and let the next editor find it.

Hugging Face’s Phonon documentation identifies a practical implementation difference: its Transformers tokenizer does not spell out language-dependent numbers, amounts, symbols, or addresses. The documentation recommends using the runtime’s normalization or writing those expressions out. Choose a normalization path deliberately and review its output. If the application changes from one implementation to another, include the spoken text in the migration review instead of assuming the same input will produce the same wording.

Build a short listening list of the terms most likely to confuse visitors: mineral names, place names, surnames, codes, units, and dates. Have an appropriate content expert confirm the intended pronunciation and meaning. Store a display spelling separately from any speech-specific spelling used to guide the tool. The workaround should not appear in captions as though it were the official name.

Listen to full passages as well as isolated terms. A sentence may place emphasis somewhere that makes a qualification easy to miss, or pause where a listener expects the thought to continue. An editor can often improve that by rewriting an overly long sentence into two clear ones. Preserve the scientific claim while making the spoken structure easier to follow; do not use a more confident delivery to disguise an uncertainty in the source material.

Cancel the old request before starting the new one

When the visitor selects another exhibit, assign the new request its own identity. Playback and generation belonging to the earlier request should lose permission to reach the speaker. This matters even if an underlying operation cannot be stopped immediately. A late chunk of old audio must not reappear after the interface has moved on. The application can discard that result by checking the request identity at the point where it queues audio.

Distinguish Stop from Pause. Pause implies that the visitor can continue from an understandable position. Stop can return the passage to its beginning and clear pending audio. Make those behaviors visible in the controls and implement them consistently. If the kiosk resumes from the middle of an unfamiliar word, a technically accurate playback position may still be a poor listening experience. Resuming at a nearby sentence boundary can be a product choice, provided the screen makes that choice clear.

Divide long descriptions into meaningful passages that can be repeated or skipped independently. The model card notes that long input is split into sentences and that prosody does not carry across an entire long text. For this installation, short editorial units can also make interruptions easier to handle. A visitor can replay the paragraph about how the specimen formed without restarting the whole exhibit. Keep enough context in each unit that it remains understandable when heard alone.

Define what happens during every waiting state. If the visitor taps Play twice while speech is preparing, avoid creating two independent playback requests. A busy indicator and a disabled duplicate action may help, while Stop should still work. If preparation fails, retain the description on screen and offer a clear retry rather than silently pretending the narration finished.

Review interruptions as complete sequences: Play, Stop, new exhibit; Play, Pause, Resume; Play, change language; restart while preparing. Watch both the controls and the speaker output. The test passes when the user’s most recent choice governs what they hear and the screen truthfully describes the state. Smooth uninterrupted narration alone would miss the failure that opened this example.

Let visitors choose sound without losing the content

Make Play a deliberate action. A quiet visitor should be able to read without a voice starting unexpectedly, and a staff member should be able to reduce or disable sound without removing the exhibit description. Put the transcript near the controls, keep it readable, and show which passage is selected. A visible volume setting is useful only if it maps to the output visitors actually hear, so check the installed audio path.

The kiosk does not need a microphone to read approved text aloud. Keeping input to touch controls simplifies this example and avoids collecting speech when the task does not require it. If another version later adds spoken commands, treat that as a separate product decision with its own collection and retention rules. A local synthesizer by itself says nothing about analytics, diagnostics, or other network traffic in the surrounding application.

Use a voice whose allowed use fits the installation. For this exercise, that means selecting an available synthetic voice after checking its terms, rather than asking for an imitation of a famous naturalist or a staff member. Tell visitors that the narration is synthetic in a plain note near the audio controls. Let them attribute the exhibit’s claims to the museum’s approved content, without implying that a real person recorded or personally endorsed each line.

Do not assume a voice file gives the application a complete voice-creation system. The Transformers documentation says Phonon uses precomputed voice latents and that the speaker codec is not released; that implementation cannot clone a recording directly. The museum needs neither cloning nor a custom voice to make the descriptions understandable. It needs a voice the team is permitted to use and an approval process that covers every passage.

For multiple languages, review each language as an editorial product. Choose the correct checkpoint, normalization settings, content, and voice, then have an appropriate speaker listen. The English model is not a substitute for a supported multilingual option. A language selector should not offer an unfinished translation simply because the interface has a place to put it.

Ship the recording plan with the software

Before opening the kiosk, assemble an acceptance set with ordinary passages and difficult cases. Include a description with a code, a date, a measurement, a long name, punctuation, and an empty content field. The empty field should lead to a controlled unavailable state rather than unrelated filler. Keep an expected spoken reading and editorial approval for the meaningful cases. A model can produce plausible speech while saying a digit or name incorrectly.

Keep measurements separate from listening judgments. Startup time, generation time, interruption delay, and peak memory tell you about operation on the chosen device. Pronunciation, missing words, intelligibility, and whether the passage preserves the approved meaning require listening and comparison. Write down the actual result of each review instead of treating a favorable public benchmark as an acceptance result for the museum’s scripts.

For fixed material, compare live synthesis with locally stored approved audio. Pre-rendering can let curators approve the exact files visitors hear and removes synthesis from the playback path. Live synthesis can be useful when approved content changes frequently or the application assembles carefully controlled passages. The choice depends on the content workflow and device, not on an obligation to generate every sentence at the moment of playback. Either option still needs reliable controls.

Version the content, voice, normalization rules, model, and runtime together. If one changes, identify which passages must be regenerated and reviewed. A cached audio file belongs to that combination, not merely to an exhibit number. Otherwise the screen can show a corrected date while an old narration continues to speak the previous one. Staff should have one clear operation for installing a complete approved release and returning to the previous release if needed.

Finish with a short operating guide at the installation. Explain how to confirm the kiosk is ready, restart it, select silent mode, and report a passage that sounds wrong. Give the report a passage identifier so the editor can find the exact content without asking staff to remember a whole sentence. Offline speech becomes useful when its failures are recoverable by the people on site: the voice stops when asked, the text remains available, and a correction can reach the next visitor as a reviewed update.