If you’ve been following OVOS for a while, you already know the pattern:

• The fun part is building a voice assistant that doesn’t rent space in someone else’s cloud.
• The unglamorous part is everything around it: Python versions, services, audio, config drift… and that one dependency that only fails on Tuesdays.

ovos-installer exists to make the unglamorous part uneventful.

And now it does that on macOS, on both Intel and Apple Silicon Macs.

No “weekend-long dependency archaeology”. No “it works until you reboot”. Just boring installs and boring updates — which is the highest compliment I can pay an installer.

What macOS support means (and what it doesn’t… yet)

macOS support is real — and it’s also deliberately scoped so we can keep it stable.

Current macOS support matrix:

• Method: virtualenv (only)
• Channel: alpha (only)
• Service manager: launchd

That’s not a forever rule. It’s the “ship one reliable path first” rule.

macOS prerequisites (aka: the four boring ingredients)

Before you run the installer, make sure you have:

1. Homebrew installed and available in your PATH

2. Xcode Command Line Tools installed:

   xcode-select --install
   

3. Homebrew Bash installed (required by ovos-installer):

   brew install bash
   

4. Microphone permission granted to your terminal app

   macOS is very polite about letting you install things, then very strict about letting you capture audio.

   Go to: System Settings → Privacy & Security → Microphone
   and enable your terminal (Terminal, iTerm2, etc.).

Quickstart (copy/paste speed-run)

sudo sh -c "$(curl -fsSL https://raw.githubusercontent.com/OpenVoiceOS/ovos-installer/main/installer.sh)"

If you’re wearing your “operator” hat (recommended), do the boring responsible thing: download the script first, read it, then run it.

Inside the TUI, pick:

• Channel: alpha
• Method: virtualenv
• Profile: ovos

The installer will provision a supported Python runtime for the virtualenv (default 3.11) using uv, so you don’t have to fight whichever Python your system feels like shipping this week.

launchd service management (without becoming a launchd expert)

macOS uses launchd, so the installer sets you up with a small wrapper that makes service management human-readable.

You’ll get an ovos command you can use like this:

ovos list

ovos status ovos
ovos status ovos-core

ovos restart ovos-core
ovos stop ovos
ovos start ovos-audio

That ovos “meta target” controls the user-level OVOS services managed by launchd.

Boring. Predictable. Exactly what we want.

Microphones on macOS: CoreAudio, minus the drama

Audio is usually where “almost working” goes to die.

To keep this boring on macOS, ovos-microphone-plugin-sounddevice is the recommended path: it’s built on python-sounddevice (PortAudio) and uses CoreAudio-friendly settings tuned for clean wake word + STT capture.

Install the plugin

If you want the newest macOS/CoreAudio tuning (the one from PR #16), install the pre-release:

pip install --pre ovos-microphone-plugin-sounddevice

Configure it in mycroft.conf

Edit your mycroft.conf (usually ~/.config/mycroft/mycroft.conf) and set the microphone module:

{
  "listener": {
    "microphone": {
      "module": "ovos-microphone-plugin-sounddevice",
      "ovos-microphone-plugin-sounddevice": {
        "device": "Built-in Microphone",
        "latency": "low",
        "multiplier": 1.0,
        "blocksize": 1024,
        "queue_maxsize": 8,

        "use_coreaudio_settings": true,
        "coreaudio_conversion_quality": "max",
        "coreaudio_change_device_parameters": false,
        "coreaudio_fail_if_conversion_required": false,

        "auto_sample_rate_fallback": true,
        "auto_channel_fallback": true,
        "auto_latency_fallback": true
      }
    }
  }
}

Device selection tips (because device names are a lifestyle choice)

• Exact name: "device": "Built-in Microphone"
• Substring match: "device": "Built-in"
• Regex match: "device": "regex:^MacBook.*Microphone"
• Numeric index: "device": 0
• Default input device: omit device or set "device": "default"

Telemetry: opt-in, install-time only (and yes, macOS is already showing up)

I like privacy by default and feedback by consent.

ovos-installer telemetry is:

• Anonymous
• Opt-in (the installer asks)
• Install-time only (nothing keeps phoning home once the install is done)

It captures things like OS name/version, architecture, Python version, install channel, and which features were enabled — useful for improving the installer and the platform without collecting personal data.

There’s a public dashboard here:

• https://telemetry.smartgic.io/ovos-installer/dashboard/

And it already shows macOS users — which is both a good signal and a mild accusation that people have been doing this the hard way. Now we can make it repeatable.

What actually landed (high level)

Two PRs did the heavy lifting:

• ovos-installer #441
  macOS support for Intel + Apple Silicon, launchd service management, and the “make it behave like the Linux experience” glue.

• ovos-microphone-plugin-sounddevice #16
  better CoreAudio tuning, smarter device selection, more runtime controls (latency, blocksize, queue sizing, gain), plus tests to keep it from regressing the moment we touch it again.

Try it on your Mac (and help us make it boring for everyone)

If you’ve got:

• a Mac Mini acting as a tiny server,
• a MacBook you want as an OVOS dev box,
• an Intel Mac you’re not ready to retire,

…this is your excuse to try OVOS on macOS using the real installer path.

If something breaks: open an issue.
If you fix something: open a PR.
If you just test and report: you’re still doing the work that makes this boring later.

Resources

• ovos-installer: https://github.com/OpenVoiceOS/ovos-installer
• PR #441 (macOS support): https://github.com/OpenVoiceOS/ovos-installer/pull/441
• ovos-microphone-plugin-sounddevice: https://github.com/OpenVoiceOS/ovos-microphone-plugin-sounddevice
• PR #16 (CoreAudio improvements): https://github.com/OpenVoiceOS/ovos-microphone-plugin-sounddevice/pull/16
• Telemetry docs: https://github.com/OpenVoiceOS/ovos-installer/blob/main/docs/telemetry.md
• Telemetry dashboard: https://telemetry.smartgic.io/ovos-installer/dashboard/

Help Us Build Voice for Everyone

OpenVoiceOS is more than software, it’s a mission. If you believe voice assistants should be open, inclusive, and user-controlled, here’s how you can help:

• 💸 Donate: Help us fund development, infrastructure, and legal protection.
• 📣 Contribute Open Data: Share voice samples and transcriptions under open licenses.
• 🌍 Translate: Help make OVOS accessible in every language.

We're not building this for profit. We're building it for people. With your support, we can keep voice tech transparent, private, and community-owned.

👉 Support the project here

Speech recognition — turning spoken words into text — has dramatically improved over the past few years. When OpenVoiceOS (OVOS) began, offline automatic speech recognition (ASR) was elusive. Today, with new ONNX-powered runtimes and models, offline STT is practical and performant even on modest hardware.

In this post we will:

• Explain the evolution of offline STT on OVOS
• Describe why ONNX matters
• Introduce the new OVOS plugins that make modern ASR work locally
• Point you to resources for both casual users and developers

Where Offline STT on OVOS Started

OVOS has historically supported many STT backends, but most were designed for cloud or desktop environments rather than small devices.

Here’s a quick historical rundown:

Full Framework Backends

Many early OVOS STT plugins wrapped models and code that required:

• PyTorch, TensorFlow, or
• Full toolkits like NVIDIA NeMo

This worked on desktops and servers but was difficult on small single-board computers (SBCs) like the Raspberry Pi because:

• Framework installs are massive (hundreds of MBs)
• Native builds of CUDA, CuDNN, etc., are complex
• Some models require dedicated GPUs to run at usable speeds

As a result, for most OVOS users, these backends were theoretical offline options. Practical use often required self-hosting distinct servers or complex custom builds.

Early Lightweight Offline Options

Some OVOS plugins attempted to address dependency bloat or offline operation early on:

✔️ ovos-stt-plugin-vosk

🔗 https://github.com/OpenVoiceOS/ovos-stt-plugin-vosk

• Based on the Vosk speech recognition library (Kaldi-based)
• Designed for local offline STT
• Limitation: While fast, existing Vosk models generally offer lower accuracy compared to modern end-to-end neural ASR.

✔️ ovos-stt-plugin-citrinet

🔗 https://github.com/OpenVoiceOS/ovos-stt-plugin-citrinet

• Citrinet models exported to ONNX
• Limitation: Models were small and fast, but few pre-trained models were available, and those that existed struggled with accuracy.

These plugins were important steps, they removed heavy dependencies, but in practice, their accuracy was rarely competitive with cloud solutions or large models.

The Practical Offline Choice Before ONNX

Whisper models from OpenAI were (and remain) a major force in open ASR.

The fasterwhisper backend provided a lightweight way to run Whisper models locally using CTranslate2 for C++ acceleration and historically has been the default go-to plugin.

• 🔗 https://github.com/OpenVoiceOS/ovos-stt-plugin-fasterwhisper
• 🔗 https://github.com/OpenVoiceOS/ovos-stt-plugin-whispercpp
• 🔗 https://github.com/TigreGotico/ovos-stt-plugin-whisper

Practically speaking, this was the only widely usable offline solution for OVOS on SBCs — provided:

• You used very small Whisper models (tiny/base), or
• You had a GPU to accelerate inference.

Without a GPU, even small Whisper models were often too slow on ARM CPUs for a snappy voice assistant experience.

So offline STT existed, but was effectively limited unless you had higher-end hardware.

Why ONNX Changes Everything

ONNX (Open Neural Network Exchange) isn’t a model; it’s a portable format plus optimized runtimes that let you run models efficiently on many platforms.

Official ONNX site: https://onnx.ai/

Key Properties

• Portable inference: Export a model once and run it anywhere that supports ONNX Runtime.
• Low dependency overhead: You don’t need PyTorch, TensorFlow, or large ML stacks.
• Hardware Agnostic: ONNX Runtime can use CPU, GPU, NPUs, and platform accelerators seamlessly:
  • CPU: Optimized kernels
  • GPU: CUDA, TensorRT
  • Apple Silicon: CoreML
  • Windows ML: DirectML
• Quantization support: Reduces model size and improves inference speed on resource-limited hardware (e.g., using int8 models).

The result: real-time or near-real-time speech recognition on devices that previously struggled to run anything but tiny models.

Architectures in Modern ASR (Quick Reference)

Modern ASR is built on several architectural paradigms. All of the following can now be exported to ONNX and run with optimized inference in OVOS:

Two New ONNX-Powered OVOS STT Plugins

1) ovos-stt-plugin-sherpa-onnx

📦 https://github.com/TigreGotico/ovos-stt-plugin-sherpa-onnx

This plugin connects OVOS with the Sherpa-ONNX ecosystem, a performant, multi-model, ONNX-centric ASR framework.

2) ovos-stt-plugin-onnx-asr

📦 https://github.com/TigreGotico/ovos-stt-plugin-onnx-asr

This plugin integrates the onnx-asr Python library directly into OVOS, giving you a simple API to run ONNX models.

We even converted some basque/spanish/catalan models for usage with the onnx-asr plugin, you can find them in ths huggingface collection

Features of the new plugins:

• Modern model families: Transducer/Zipformer, Paraformer, Parakeet, Canary, Whisper, GigaAM, Moonshine
• Auto-download of models
• Quantized models for low-power devices
• Hardware Acceleration: Works well on both CPU and GPU (if available)

What This Means for OVOS Users

For Casual Users

• Real offline STT — no internet required.
• Better accuracy than previous lightweight plugins.
• Easier installation processes.

For Developers

• Full access to modern ASR architectures.
• Benchmark and swap models without rewriting code.
• Experiment with ONNX Runtime acceleration backends.

In Summary

The landscape of offline speech recognition on OpenVoiceOS has matured:

With these new ONNX plugins, OVOS users get the most capable offline STT stack yet — faster, more accurate, and deployable in more environments than ever before.

Help Us Build Voice for Everyone

OpenVoiceOS is more than software, it’s a mission. If you believe voice assistants should be open, inclusive, and user-controlled, here’s how you can help:

• 💸 Donate: Help us fund development, infrastructure, and legal protection.
• 📣 Contribute Open Data: Share voice samples and transcriptions under open licenses.
• 🌍 Translate: Help make OVOS accessible in every language.

We're not building this for profit. We're building it for people. With your support, we can keep voice tech transparent, private, and community-owned.

👉 Support the project here

OVOS & VisioLab

We represented OpenVoice OS to promote our FOSS (free and open-source) framework. I was also there on behalf of VisioLab (the tech innovation department of Visio). My pitch focused on the VoiceLab project, which centers on testing and prototyping new voice interactions for the blind and visually impaired—early adopters of voice-first interfacing. Additionally, we looked for collaborators to help build a truly open-source Dutch TTS through the subproject The Voice of Holland.

We had many fascinating conversations with like-minded people. Once visitors realized we had no commercial interest and were simply there to learn, exchange knowledge, and promote a sovereign platform, the ice broke quickly. It was refreshing to connect as peers in such an open environment.

LEGO

The interest in OpenVoiceOS was wonderful to see. Using LEGO blocks as a metaphor for the framework's modularity proved to be a great conversation starter ("Hey, what’s that LEGO all about?"). These modules—including voice activity detection, automatic speech recognition (ASR), and intent matching—form the OVOS pipeline.

This modularity aligned perfectly with the day's themes. New speech models appearing weekly on HuggingFace were the "talk of the town." I especially enjoyed demonstrating this flexibility: just the evening before the event, I swapped my favorite OVOS-Google-STT plugin for a newly released offline, open-source ASR model (NVIDIA parakeet-tdt-0.6-v3-onnx).

Thanks to an Apache 2.0 licensed OVOS-onnx-ASR-plugin created by the OVOS lead developer only hours after the model's release—wow, that was fast!—we could give a live demo of a completely local setup.

It performed with the speed of proprietary online plugins; you couldn't tell the difference from the outside! The next challenge is testing this on a Raspberry Pi 4 to see if we can maintain that performance.

AI Voice Personas

We also discussed the rise of AI speech agents —essentially LLMs with speech I/O. While new shiny agents like unmute.sh are impressive, they often require significant hardware to achieve low latency. According to their GitHub documentation, they run STT, TTS, and the LLM server on three separate GPUs to reach their target performance.

Our focus remains on local, private home devices that -just work- and are fast and usable without a massive backend. Our work on "OVOS-persona" is ongoing; whether it acts as the start of the pipeline or a fallback, the goal is to provide users with modular choices. They are in control.

Looking Forward

It was a pleasure to meet organizers and researchers like Matt Coler (University of Groningen). We share the ambition to support "small" or underexposed languages and user groups, such as people with speech disorders or specific dialects. By joining forces with this network of innovators, we can reduce dependency on Big Tech and prove that we can be self-sufficient in speech technology.

References

• Dutch Speech Tech Day 2026
• VoiceLab Visio
• OVOS Technical Manual - Personas
• OVOS ONNX ASR Plugin

Help Us Build Voice for Everyone

OpenVoiceOS is more than software — it’s a mission.

If you believe voice assistants should be open, inclusive, and user-controlled, there are many ways to help:

• 💸 Donate — support development, infrastructure, and long-term sustainability
• 📣 Contribute open data — share voice samples and transcriptions under open licenses
• 🌍 Translate — help make OpenVoiceOS accessible in every language

We’re not building this for profit.

We’re building it for people.

👉 Support the project here

5× Faster than typing and far smarter than keystrokes

For decades, we’ve accepted keyboards, touchscreens, and endless menus as the default way to interact with computers. We type emails. We click buttons. We fill in forms.

And yet, none of this is natural.

Humans didn’t evolve to communicate through keyboards. We evolved to speak.
This belief has always been at the core of OpenVoiceOS: voice-first interaction should be open, user-controlled, and respectful of privacy.

Now, as artificial intelligence becomes more capable than ever, the mismatch is obvious: incredibly powerful systems are still locked behind slow, outdated interfaces.

Voice is not just returning. It’s becoming essential.

Speed matters and voice wins, hands down

The numbers are hard to ignore:

• Average speaking speed: ~130–160 words per minute
• Average typing speed: ~40–60 words per minute (experienced typists)
• Most people: closer to 20–30 words per minute

That means speaking is up to five times faster than typing.

In real-world terms, this translates to:

• Less time entering information
• Fewer interruptions to your workflow
• Faster access to systems, tools, and knowledge

Stanford University study showed that voice input on smartphones was around three times faster than typing and often more accurate, thanks to modern deep-learning-based speech recognition.

Voice removes the input bottleneck

Speech removes the input bottleneck.
Humans think faster than they type. Voice aligns input speed with natural cognition, while keyboards artificially slow interaction with modern AI systems.

Speed isn’t a luxury. At scale, it’s a competitive advantage.

AI Has leaped forward however interfaces have not

Over the last few years, AI has taken a massive leap forward.

Large Language Models, autonomous agents, copilots, and smart systems can reason, summarize, plan, and act. Yet most of them are still accessed through:

• Keyboards
• Text boxes
• Click-heavy user interfaces

This creates a clear bottleneck.

Powerful intelligence, trapped behind slow input.

At OpenVoiceOS, we see voice as the missing interface layer for modern AI — one that connects humans to intelligence at the speed of thought.

Voice allows you to:

• Talk directly to your smart environment
• Control AI agents and language models naturally
• Interact without breaking focus or switching context

And crucially, this does not require sending your data to the cloud.
OpenVoiceOS is designed to be able to run locally, offline, and is fully open source.

Voice isn’t a novelty feature. It’s the most efficient way to access intelligence.

Voice-First is more natural and more inclusive

Voice changes how we interact across environments:

• In homes and offices
• On factory floors and in warehouses
• In cars, on bikes, and on the move
• In healthcare, logistics, and field work

The advantages are immediate and practical:

• Hands-free operation: safer and more efficient
• Faster documentation: speak instead of type
• Accessibility by design: empowers people with disabilities, RSI, or limited mobility

Unlike traditional UI shortcuts, voice doesn’t require training. Speaking is universal.

This focus on accessibility and inclusivity is a recurring theme within the OpenVoiceOS community, where voice is not treated as a convenience feature, but as a fundamental interface for everyone.

With OpenVoiceOS, voice-first also means:

• No forced cloud dependency
• No opaque data harvesting
• Full transparency and control

Fast. Local. Private.

Voice makes AI smarter, too

Voice isn’t just faster, it changes how we communicate with AI.

Spoken interaction naturally provides:

• More context
• Richer phrasing
• Clearer intent

When connected to language models and agents, voice-based interaction often results in better prompts and more accurate responses without users needing to learn prompt engineering or special syntax.

This makes voice a natural companion to LLMs and AI agents, an idea we explore further in our writing about voice-driven AI workflows within our blog.

In short: voice reduces friction for humans and for AI systems.

Early adopters gain the edge

Voice technology has existed for years but only now do we have the AI capabilities to fully unlock its potential.

Organizations and developers who adopt voice-first thinking today will:

• Build faster, more intuitive user experiences
• Reduce interaction cost and cognitive load
• Create systems that scale naturally with AI

We’ve spent decades optimizing keyboards and touchscreens.

The future interface doesn’t use keyboards.

It speaks!

At OpenVoiceOS, we’re building that future, open, local, privacy-respecting, and community-driven.

Voice isn’t just faster. It’s smarter.

Help Us Build Voice for Everyone

OpenVoiceOS is more than software — it’s a mission.

If you believe voice assistants should be open, inclusive, and user-controlled, there are many ways to help:

• 💸 Donate — support development, infrastructure, and long-term sustainability
• 📣 Contribute open data — share voice samples and transcriptions under open licenses
• 🌍 Translate — help make OpenVoiceOS accessible in every language

We’re not building this for profit.

We’re building it for people.

👉 Support the project here

This blog was originally posted in the TigreGotico website

As the lead developer of OpenVoiceOS, maintained by a non-profit, and the creator of HiveMind, I’ve always believed in open, privacy-respecting voice technology. What I did not anticipate was how quickly these tools would end up in industrial research, especially without any direct involvement from me.

The COALA and WASABI EU projects have built an entire industrial voice-assistant framework around OVOS + HiveMind, integrating them with their own tools, UI, and conversation engines.

I am not involved with these deployments, but the fact that the stack is being adopted organically is a strong validation of its design.

WASABI Open Call

The 2nd WASABI Open Call to provide financial support to at least 10 experiments led by SMEs recently closed. This open call is designed to support AI-based digital assistance experiments involving SMEs from manufacturing.

All WASABI Open Call experiments are required to:

• run the WASABI/COALA OVOS Docker stack
• connect via HiveMind
• develop a custom OVOS Skill containing their industrial logic

The usage of OVOS/Hivemind is explained in these 2 documents from the Wasabi project:

• Deliverable D2.1
• Deliverable D2.4

Examples of Industrial Applications

1. Worker Guidance & Assembly Support

Experiments like TICONAI and SKITE are using OVOS skills to guide workers during complex tasks such as assembling components, validating procedures, or providing step-by-step instructions hands-free.

2. Quality Control and Error Reduction

Projects like WALLABI and HUMANENERDIA focus on providing workers with real-time instructions and checklists to prevent mistakes. Voice assistants help operators verify settings, remember safety checks, or cross-check parameters.

3. Predictive Maintenance Assistance

Experiments such as GENIUS-PM use the assistant to give maintenance techs quick access to machine health data, fault explanations, and repair steps—especially when their hands are occupied.

4. Logistics, Material Handling & Warehouse Support

VELO and AIVEA use voice to help workers locate items, confirm inventory, or check delivery tasks while moving around a shop floor.

5. Onboarding and Training

ONBOARD and AI-MODE test how new employees can be guided through tasks using voice guidance, reducing the burden on supervisors.

6. Sustainability, Waste Tracking & Resource Efficiency

VAFER integrates voice interfaces with systems that monitor recycling, material reuse, and resource flows—hands-free reporting in factory environments.

All of these rely on OVOS and on HiveMind for routing communication between devices, Android UI, and backend systems.

What COALA/WASABI Built on Top of OVOS

Although the projects produced no open-source industrial skills, they did create several components around OVOS + HiveMind:

1. A RASA-based Domain Assistant (DA)

Earlier COALA research developed a RASA NLP pipeline trained on manufacturing conversations (about quality checks, troubleshooting, machine operation). In WASABI, this RASA engine is plugged into OVOS as a skill, handling domain-specific dialog.

2. The COALA Android App

An Android front-end for workers, connecting to OVOS through HiveMind.

Early version released here: https://github.com/BIBA-GmbH/Mycroft-Android

Features include:

• login via Keycloak
• text or voice chat
• UI for instructions, warnings, and notes
• HiveMind-based messaging

3. A Full Docker-Based Industrial Stack

Both projects ship a preconfigured Docker environment bundling:

• OVOS
• HiveMind
• Keycloak (user management)
• RASA NLP engine
• COALA connector services

This forms the standard industrial voice-assistant stack that all WASABI experiments must deploy.

4. An Industrial Speech Dataset

COALA published a speech dataset recorded in factories and workshops: https://zenodo.org/record/8268928

Why Industry Chooses OVOS + HiveMind

The appeal is straightforward:

• Full transparency (crucial for regulated sectors)
• Local/edge deployment (no cloud dependency)
• Easy to integrate into existing equipment
• Modular enough for custom proprietary skills
• Distributed voice networks (HiveMind satellites across a factory)

In short: the combination is flexible, vendor-neutral, and respects industrial data constraints.

Closing Thoughts

I didn’t set out to build an industrial standard. I set out to build something open, reliable, and user-controlled.

Seeing OVOS and HiveMind adopted by COALA/WASABI, without my involvement or promotion, is a quiet but powerful sign that open-source voice technology is maturing.

A transparent, modular voice stack is no longer just a community dream.

It’s becoming part of the industrial toolset used to guide workers, reduce errors, improve maintenance, and ensure safer operations.

This is only the beginning.

Help Us Build Voice for Everyone

OpenVoiceOS is more than software, it’s a mission. If you believe voice assistants should be open, inclusive, and user-controlled, here’s how you can help:

• 💸 Donate: Help us fund development, infrastructure, and legal protection.
• 📣 Contribute Open Data: Share voice samples and transcriptions under open licenses.
• 🌍 Translate: Help make OVOS accessible in every language.

We're not building this for profit. We're building it for people. With your support, we can keep voice tech transparent, private, and community-owned.

👉 Support the project here

This blog was originally posted in the TigreGotico website

Today marks an exciting milestone for linguistic preservation! We're thrilled to announce the release of g2p_barranquenho, the very first Grapheme-to-Phoneme (G2P) phonemizer for Barranquenho, a truly unique Ibero-Romance language spoken in the Portuguese municipality of Barrancos.

This isn't about a technical achievement; it's a step towards safeguarding and revitalizing a language that embodies a rich cultural heritage.

Why Barranquenho, and Why Now?

Barranquenho stands at a fascinating crossroads of Portuguese and Spanish linguistic traditions, reflecting centuries of cross-border interaction. Despite its distinctiveness, resources for Barranquenho have historically been scarce, making it a challenging language for digital representation and AI development.

However, a monumental effort from the Barrancos Municipal Council is changing that. Just recently, the Council made available three foundational linguistic documents, an "enormous step" for Barranquenho culture:

• Dicionário de Barranquenho (Barranquenho Dictionary)
• Convenção Ortográfica do Barranquenho (Barranquenho Orthographic Convention)
• Gramática Básica do Barranquenho (Basic Barranquenho Grammar)

These publications, highlighted in their official announcement "Un Enormi Passu para u Barranquenhu i para a Cultura Barranquenha!", provide the crucial backbone for our work. The Convenção Ortográfica do Barranquenho in particular has been instrumental, offering the consistent rules we needed to build our G2P model.

What is a G2P Phonemizer?

In simple terms, a G2P phonemizer is a system that takes a written word (graphemes) and converts it into its phonetic representation (phonemes). Think of it as teaching a computer how to "pronounce" a word, even if it's never heard it before. For Barranquenho, this means translating its unique spelling into the International Phonetic Alphabet (IPA).

Our rule-based phonemizer accounts for Barranquenho's distinct phonetic features, including vowel allophony, nasalization, and the specific pronunciations of consonants like 'r' and 's', which can vary significantly from standard Portuguese or Spanish.

"Un Enormi Passu para u Barranquenhu i para a Cultura Barranquenha" -> "ũ ẽjoɾmj pasu paɾɐ u bɐrɐ͂keɲu j paɾɐ ɐ kultuɾɐ bɐrɐ͂keɲɐ"

The Power of this First Step

There is still a long way to go before Barranquenho speakers no longer need to switch to Portuguese or Spanish to interact with voice technology. The creation of this G2P phonemizer is more than just a cool linguistic tool; it's the foundational layer for developing advanced AI capabilities for Barranquenho. With a reliable way to map written words to their sounds, we can unlock:

• Speech-to-Text (STT) Systems: Imagine speaking in Barranquenho and having your words accurately transcribed. This could revolutionize documentation, communication, and accessibility.
• Text-to-Speech (TTS) Systems: Give digital voices the ability to speak Barranquenho, opening doors for educational tools, audiobooks, and interactive experiences.

This work aligns perfectly with our mission of making voice AI accessible for everyone in any language.

Join Us: Help Bring Barranquenho Voices to AI!

While the orthographic convention gives us the rules for pronunciation, real-world speech data is invaluable for training robust AI models.

We are putting out a call to the Barranquenho community and anyone passionate about linguistic preservation:

We need recordings of spoken Barranquenho!

Whether you're a native speaker, an enthusiast, or a linguist, your voice can help us create the next generation of Barranquenho AI resources. If you are interested in contributing, please reach out to us!. Every voice counts, and together, we can ensure that Barranquenho thrives in the digital age.

Let's make some noise for Barranquenho! 📢

Help Us Build Voice for Everyone

OpenVoiceOS is more than software, it’s a mission. If you believe voice assistants should be open, inclusive, and user-controlled, here’s how you can help:

• 💸 Donate: Help us fund development, infrastructure, and legal protection.
• 📣 Contribute Open Data: Share voice samples and transcriptions under open licenses.
• 🌍 Translate: Help make OVOS accessible in every language.

We're not building this for profit. We're building it for people. With your support, we can keep voice tech transparent, private, and community-owned.

👉 Support the project here

Have you ever wanted to hear a computer speak in an accent you love, or in a language that's rarely supported by big tech?

Today we’re releasing new experimental Text-to-Speech (TTS) models for Asturian (ast) and Aragonese (an), two beautiful minority Romance language spoken by communities who almost never get access to modern speech technology.

These models represent a small but meaningful step toward a larger mission: help any under-resourced language build openly available TTS voices using only community data and ethical voice-cloning techniques.

Why This Work Matters - A Short Reality Check

Most languages still lack even a single usable open TTS voice. Not because the technology doesn’t exist, but because:

• high-quality monolingual datasets are rare
• speakers often can’t safely provide the many hours required
• dialect diversity makes a single “official” voice unrealistic
• basic tools (phonemizers, lexicons, G2P) often don’t exist

Meanwhile, these communities still need TTS, for education, accessibility, media creation, cultural preservation, and linguistic pride.

Large tech companies rarely prioritise minority languages. Their incentives are simple: supporting a language only brings value if it brings new users or data.

For speakers of Asturian or Aragonese, who can also use Spanish, this lack of support nudges people away from their own languages. Over time, that invisibility contributes to language shift and erosion.

As a non-profit, we have different priorities: we want to empower all users, preserve linguistic diversity, and treat language as accessibility. This project is part of that mission.

So, how did we do it? We used a clever, hybrid approach that combines existing resources with cutting-edge voice cloning technology.

The "Low-Resource" Challenge

Imagine you want a computer to speak with a very specific voice, perhaps your own, or that of a beloved family member. Now imagine you only have a few seconds of that person speaking. That's our "low-resource donor voice."

At the same time, we have access to large Automatic Speech Recognition (ASR) datasets, like Mozilla Common Voice, which contain recordings of many different people. The problem is, it's not a single, consistent voice.

Our goal was to "transfer" the specific sound of our donor voice onto the vast amount of data available in these multi-speaker ASR datasets.

Our Hybrid Solution: A Step-by-Step Journey

Here's a simplified look at the process we followed (for a more detailed, technical explanation, check out our Whitepaper on Hybrid TTS Dataset Synthesis):

1. Gathering Our Raw Materials:

• We started with text and audio from two datasets: Common Voice Scripted Speech 23.0 - Asturian and the Common Voice Scripted Speech 23.0 - Aragonese. These provided us with many text transcripts and their corresponding multi-speaker audio.
• We also had a short recording of our "donor voice" – the target voice we wanted the TTS model to learn.

2. Audio Quality Filtering and Preparation:

• We converted all audio to a standard format and ensured the volume was consistent across all recordings (normalization).
• We trimmed silence from the beginning and end of each recording.
• We filtered out recordings where people spoke too fast or too slow (outliers based on Words-Per-Minute), keeping only the most natural and consistent segments. This focused our dataset on the best quality transcripts.

3. The Magic of Voice Cloning (Zero-Shot Revoicing):

• This is where modern AI comes in! Instead of training a complex model from scratch, we used an off-the-shelf zero-shot voice cloning solution.
• This system was given a short reference clip of the donor voice. It uses this clip to learn the unique qualities of the voice.
• We then fed our filtered ASR dataset into this cloning system. The original multi-speaker audio was discarded; the cloning tool simply generates new audio in our target donor voice. The result? A new dataset of Asturian/Aragonese audio, all spoken in a single, consistent voice!

4. Training the Final TTS Model:

• With our brand-new, high-quality, single-speaker datasets, we could finally train our TTS models.

About Pronunciation & Phonemizers

These models were trained directly on graphemes, we did not use a phonemizer. Good G2P (grapheme-to-phoneme) tools for Asturian and Aragonese are scarce. A phonemizer usually improves pronunciation and, importantly, allows IPA input at runtime to force pronunciations when needed.

If you know of an existing phonemizer, have lexicons/pronunciation data, or want to help train one, please get in touch. This would materially improve future releases.

The Results:

The results are not perfect, our goal was mainly to validate that this approach works.

We used phoonnx to train VITS models, VITS is very performant and can run basically anywhere, it is also very easy to train without needing massive GPUS making it perfect for experimentation

There are many better architectures we can explore in the future to train truly natural sounding voices!

"L'arcu la vieya ye un fenómenu ópticu y meteorolóxicu que produz l'apaición d'un espectru de lluz continu nel cielu cuando los rayos del sol trespasen pequeñes partícules de mugor conteníes n'atmósfera terrestre. La forma ye la d'un arcu multicolor col roxo hacia la parte esterior y el viola hacia la interior. El arco iris duble, ye menos avezau a vese, y tien los colores invertíos, esto ye, el roxo hacia dientro y el viola hacia l'esterior."

Download: Asturian — dii (female) and Asturian — miro (male)

"L'arco de sant Chuan ye un fenomeno optico y meteorolochico que produce l'aparición d'un espectro de luz contino en o cielo cuan os rayos d'o sol trescruzan chicotas particlas d'humidat situatas por l'atmosfera terrestre. A forma suya ye a d'un arco multicolor con o royo en a parti exterior y o morau en a interior. No ye tan cutiano l'arco de sant Chuan dople, que incluye un segundo arco mas tenue con as colors chiratas, ye dicir o royo en l'interior y o morau en l'exterior."

Download: Aragonese — dii (female) and Aragonese — miro (male)

These models are a significant step forward for Asturian and Aragonese language technology. It demonstrates how modern AI, combined with careful data preparation, can empower underserved languages and bring them into the digital age. We're excited to see what developers and enthusiasts will build with it!

Help Us Build Voice for Everyone

OpenVoiceOS is more than software, it’s a mission. If you believe voice assistants should be open, inclusive, and user-controlled, here’s how you can help:

• 💸 Donate: Help us fund development, infrastructure, and legal protection.
• 📣 Contribute Open Data: Share voice samples and transcriptions under open licenses.
• 🌍 Translate: Help make OVOS accessible in every language.

We're not building this for profit. We're building it for people. With your support, we can keep voice tech transparent, private, and community-owned.

👉 Support the project here

In an era dominated by probabilistic giants like Large Language Models (LLMs), it might seem counterintuitive to advocate for a more traditional approach to Artificial Intelligence. Yet, OpenVoiceOS (OVOS) deliberately grounds its core architecture in Symbolic AI, often referred to as Good Old-Fashioned AI (GOFAI).

This isn’t nostalgia, it’s engineering discipline. GOFAI provides predictable precision where voice assistants need it most: deterministic, fast, and transparent decision-making. Rather than chasing generalized intelligence, OVOS builds on logic, structure, and explainability, the ingredients of reliability.

The GOFAI Philosophy: Precision Over Probability

Symbolic AI, the dominant paradigm from the 1950s through the 1990s, is built on explicit rules and formal logic. Instead of learning from massive datasets, it reasons with structured knowledge.

While LLMs are masters of generalization, they operate in a world of probabilities, a risky trait for voice assistants. For a task like “set a timer for three hours,” almost correct isn’t good enough. OVOS rejects this uncertainty for the foundational layers of its system, relying on GOFAI to handle the tasks that demand perfect precision: parsing numbers, times, colors, and other concrete entities.

This represents a deliberate trade-off: OVOS accepts the cost of manual rule design in exchange for guaranteed correctness, full transparency, and instant local execution, traits essential for embedded, privacy-respecting systems.

Key Advantages of the Rule-Based Approach

• 🪞 Interpretability and Debugging – Every rule is explicit. When something goes wrong, a developer can pinpoint exactly where and why. This transparency makes open-source collaboration possible, any contributor can trace and fix an issue without black-box guesswork.

• ⚡ Performance and Efficiency – Static rule sets mean ultra-low latency and negligible compute load. Unlike LLMs that require large memory and GPU cycles, GOFAI parsers run instantly on modest hardware, ideal for offline or embedded devices.

• 🎯 Guaranteed Precision – GOFAI is often criticized as “brittle” beyond its domain. But for tightly scoped operations, like setting timers, adjusting volume, or parsing commands, this rigidity is a feature, not a flaw. It ensures the system behaves predictably every single time.

The OVOS Parser Toolkit: GOFAI in Action

OVOS integrates a family of rule-based parsers that each specialize in a precise data type. They’re distributed as standalone Python packages—available to any developer needing high-precision, multilingual parsing.

Within OVOS, these parsers aren’t used for broad Named Entity Recognition (NER). Instead, they’re invoked after an intent is identified. Once a skill knows what kind of data to expect, these parsers ensure it’s extracted and converted flawlessly.

Numerical Mastery — ovos-number-parser

Parsing numbers is deceptively complex. Humans use digits, words (“twenty”), ordinals (“first”), and fractions (“half”), often mixing them fluidly. ovos-number-parser handles these with meticulous, multilingual rule sets to produce exact numeric values.

This matters more than it seems: even “one billion” means different things across languages. English uses the short scale (1,000,000,000), while French or German follow the long scale (1,000,000,000,000). Rule-based, language-aware parsing guarantees consistent results across locales, critical for mathematical accuracy in global deployments.

Temporal Precision — ovos-date-parser

Time is contextual: “tomorrow at noon” means nothing without a reference point. ovos-date-parser converts these human phrases into exact datetime objects, handling relative expressions like “three days ago” or “next Friday” with surgical precision.

Identifying the Spectrum — ovos-color-parser

For tasks like setting smart light colors or adjusting UI themes, ovos-color-parser maps natural language directly to color values. It recognizes everything from “dark goldenrod” to RGB notation using explicit syntax rules and lookup tables.

This is a textbook GOFAI application: a deterministic, low-latency parser that achieves perfect accuracy without machine learning overhead.

The Language Linchpin — ovos-lang-parser

The ovos-lang-parser extracts language references from user commands, for instance, turning “How do I say ‘hello’ in French?” → "French" → "fr" (BCP-47 code).

The Symphony: GOFAI in Harmony

The power of OVOS’s design becomes clear when these parsers work together.

Consider what needs to happen in the command:

“In three hours, the light should be set to cyan at fifty percent brightness.”

1. The intent engine activates the relevant skills (timer and light control).
2. The timer skill uses ovos-date-parser to resolve “in three hours” to a future datetime.
3. The light control skill uses ovos-color-parser to map “cyan” to an exact color code.
4. The same skill calls ovos-number-parser to convert “fifty percent” to the value 0.5.

All of this happens locally, instantly, and deterministically, no cloud, no lag, no guesswork.

The Future is Collaborative and Deterministic

Building on GOFAI is not a step backward, it’s a step toward trustworthy AI. OVOS’s rule-based foundation ensures reproducibility, transparency, and full user control.

While refining these rules demands human expertise, the classic knowledge bottleneck, OVOS turns that into a feature, not a flaw. By inviting developers to become knowledge engineers, it transforms AI development into a collective, interpretable, and sustainable process.

In a world chasing statistical magic, OVOS stands as proof that determinism is not limitation, it’s reliability. A system you can understand is a system you can trust.

Help Us Build Voice for Everyone

OpenVoiceOS is more than software, it’s a mission. If you believe voice assistants should be open, inclusive, and user-controlled, here’s how you can help:

• 💸 Donate: Help us fund development, infrastructure, and legal protection.
• 📣 Contribute Open Data: Share voice samples and transcriptions under open licenses.
• 🌍 Translate: Help make OVOS accessible in every language.

We're not building this for profit. We're building it for people. With your support, we can keep voice tech transparent, private, and community-owned.

👉 Support the project here

We're thrilled to announce a new feature in OpenVoiceOS (OVOS) that aims to improve how your device listens: Pre-Wake-VAD (Voice Activity Detection). This new logic improves performance, reduces false activations, and makes OVOS an even more delightful and reliable voice assistant.

The Old Way vs. The New Breakthrough

Before Pre-Wake-VAD, the OVOS listener loop operated in a straightforward manner:

• 1. The system was always listening for the wake word (WW).
• 2. Upon hearing the WW, it started recording the user's request.
• 3. VAD was used after the wake word to detect when the user finished speaking.

This constant listening for the wake word consumed more CPU and, critically, was susceptible to false activations. Random noises, music, or even animal sounds could sometimes trigger the wake word.

The Pre-Wake-VAD Logic: A Smarter Sequence

With the new feature, we've flipped the script. The system now follows a more intelligent, two-stage listening process:

• 1. Wait for Speech (VAD First): The system first waits to detect any human speech using VAD.
• 2. Listen for Wake Word (WW Second): Only after speech is detected does the system engage the more CPU-intensive wake word engine.
• 3. Timeout: If the wake word is not detected within 5 seconds of the initial speech detection, the system assumes it was not an activation and returns to the VAD-only 'wait for speech' state.

Two Massive Wins for OVOS Users

This seemingly small change delivers two enormous benefits:

CPU Reduction

VAD is inherently less expensive to run than a complex wake word engine. By spending the vast majority of its idle time in the low-cost VAD stage, OVOS uses slightly less CPU overall. This is fantastic news for users running OVOS on resource-constrained or battery-powered devices.

Reduced False Activations

This is the real game-changer. The wake word engine no longer has to focus on distinguishing wake-word speech from non-speech sounds like music, background noise, or random audio spikes.

• The VAD acts as a powerful noise filter, ensuring only actual human speech reaches the wake word engine.
• The wake word engine can now concentrate solely on its core task: distinguishing wake-word speech from non-wake-word speech.

This collaborative approach has been shown to massively reduce the false activation rate of OVOS, making your interaction with the assistant smoother and less interrupted!

A Huge Boost for the Vosk Wake Word Plugin

The introduction of Pre-Wake-VAD is particularly exciting for the popular Vosk wake word plugin.

For those unfamiliar, the Vosk plugin is incredible because it allows users to change their wake word simply by editing a text string in a config file, no data collection, no model training required! However, this flexibility sometimes came with a higher false activation rate.

With Pre-Wake-VAD, that concern is largely eliminated. By getting rid of false positives caused by non-speech audio, this new feature makes the versatile, text-configurable Vosk plugin far more usable and reliable for everyone.

Stay tuned! We’ll be sharing the comprehensive benchmark results in an upcoming blog post, but early results confirm a massive difference in false activations!

How to Enable Pre-Wake-VAD

To start using this new noise-filtering feature, you need to ensure you have the correct version of the listener package and update your configuration file.

You must be running at least version 0.5.0 of the listener package. You can update it using pip:

pip install --upgrade ovos-dinkum-listener

Add the following parameter inside the "listener" section of your mycroft.conf file to enable the Pre-Wake-VAD logic:

{
  "listener": {
    "vad_pre_wake_enabled": true
  }
}

Once both steps are complete, restart your OVOS service, and you'll be using the new, smarter listening loop!

Help Us Build Voice for Everyone

OpenVoiceOS is more than software, it’s a mission. If you believe voice assistants should be open, inclusive, and user-controlled, here’s how you can help:

• 💸 Donate: Help us fund development, infrastructure, and legal protection.
• 📣 Contribute Open Data: Share voice samples and transcriptions under open licenses.
• 🌍 Translate: Help make OVOS accessible in every language.

We're not building this for profit. We're building it for people. With your support, we can keep voice tech transparent, private, and community-owned.

👉 Support the project here

For years, the OpenVoiceOS community has relied on the Precise-lite wake word engine. It's the core of how you bring your voice assistant to life! However, as technology evolves, so must we. The time has come to ensure future compatibility and even better performance on modern hardware.

The Problem: Outdated Dependencies

The original Precise implementation depended heavily on tflite_runtime and specific, older versions of other packages, notably requiring numpy<2.0.0. This setup has been a growing headache:

• ⚠️ Deprecation: tflite_runtime is becoming increasingly difficult to install and maintain, especially with recent versions of Python.
• 🐍 Python Version Incompatibility: The strict dependency on older packages was creating friction and installation failures for users adopting newer Python releases.

This friction was an unnecessary barrier to entry for new users and a source of frustration for existing ones. We knew we had to fix it.

The Solution: Migrating to ONNX!

We've completely overhauled the Precise wake word plugin by exporting Precise models to the ONNX format (Open Neural Network Exchange).

Introducing ovos-ww-plugin-precise-onnx

We are thrilled to announce the official release of the new plugin: ovos-ww-plugin-precise-onnx!

By adopting ONNX, we eliminate the reliance on the problematic tflite-runtime package. ONNX provides a standardized, performant, and future-proof format for machine learning models, ensuring better compatibility across different systems and hardware.

You can find all available Precise models, now converted to ONNX, in our dedicated repository: precise-lite-models.

The Unexpected Performance Bonus

While the primary goal was to fix installation woes, the move to ONNX has delivered an unexpected performance boost!

Initial testing on a Raspberry Pi 5 shows a significant reduction in CPU usage:

That's a nice efficiency gain, allowing your OVOS system to dedicate more resources to running skills and other tasks! This makes OpenVoiceOS even lighter and faster on edge devices like the Raspberry Pi.

Get the Upgrade Today!

This migration ensures that the popular Precise engine remains a stable, high-performance option for the OpenVoiceOS community for years to come. Enjoy the easier installation, greater stability, and lower CPU usage!

Update your installation and try the new ONNX-powered Precise for yourself!

• New Plugin: ovos-ww-plugin-precise-onnx
• ONNX Models: precise-lite-models

Help Us Build Voice for Everyone

If you believe that voice assistants should be open, inclusive, and user-controlled, we invite you to support OVOS:

• 💸 Donate: Your contributions help us pay for infrastructure, development, and legal protections.

• 📣 Contribute Open Data: Speech models need diverse, high-quality data. If you can share voice samples, transcripts, or datasets under open licenses, let's collaborate.

• 🌍 Help Translate: OVOS is global by nature. Translators make our platform accessible to more communities every day.

We're not building this for profit. We're building it for people. And with your help, we can ensure open voice has a future—transparent, private, and community-owned.

👉 Support the project here

Open Voice OS (OVOS) has always been about freedom and flexibility, giving users full control over their voice assistants and how they connect with the world. But freedom also brings a challenge: ensuring that all these independent components can understand and work with each other.

That’s where standards and interoperability come in.

Today, OVOS is doubling down on its commitment to protocol alignment, not by locking into a single ecosystem, but by speaking the languages of many. This post outlines where we are now and where we’re going, as OVOS evolves into a truly interoperable, protocol-aware voice platform. Much of this work is supported by the NGI0 Commons Fund, helping us build a more open, connected, and privacy-respecting voice ecosystem.

Why Standards Matter

Voice technology thrives when systems can communicate. Whether you're connecting a speech-to-text engine to a dialogue manager, or bridging a local agent to a cloud service, the key is clear, consistent interfaces.

Interoperability means:

• 🧩 Plug-and-play integration between tools, frameworks, and agents
• ⚙️ Reuse of existing infrastructure instead of reinventing the wheel
• 🔄 Resilience - the freedom to swap out components without breaking everything else

In short: standards keep the open in Open Voice OS.

Near-Future Work: MCP, UTCP, and A2A

A major focus for upcoming OVOS releases is protocol-level interoperability. Several new standards are being explored to allow OVOS to seamlessly connect with external AI ecosystems.

This is part of OVOS’s broader move toward multi-agent systems, exemplified by the ovos-persona-pipeline, which allows users to change the personality of OVOS on demand , effectively switching to an entirely new agent context. These same personas will be the ones participating in MCP, UTCP, and A2A communication once these protocols land.

Model Context Protocol (MCP) and Universal Tool Calling Protocol (UTCP)

The Model Context Protocol (MCP) defines how agents and tools can exchange structured context and reasoning requests. In the near future, OVOS plans to both consume MCP-compatible tools and expose its own services (like STT, TTS, translation, and skills) over MCP.

This would allow external systems — including other assistants or orchestration layers — to treat OVOS capabilities as MCP tools.

In parallel, we’re also experimenting with Universal Tool Calling Protocol (UTCP). While MCP and UTCP have overlapping goals, they serve slightly different audiences. OVOS intends to support both, ensuring maximum compatibility and easy integration across ecosystems.

“We like UTCP but we love interoperability.”

Our goal is to make OVOS a universal interface layer, capable of understanding and serving requests in either protocol.

Agent-to-Agent Protocol (A2A)

Finally, we’re integrating the Agent-to-Agent (A2A) protocol to allow multiple agents to discover, communicate, and collaborate dynamically.

This work is already underway in the ovos-persona-server, and will eventually power multi-agent orchestration where different personas or solver plugins can coordinate tasks collaboratively.

The OVOS Messagebus Protocol

Under the hood, OVOS uses a websocket-based JSON messagebus to communicate internally. Historically, message formats were somewhat ad hoc, but that’s changing.

An index of Pydantic models is now being developed to describe all known OVOS message types forming what we call the OVOS Messagebus Protocol.

This documentation effort will make it easier for external tools, dashboards, or bridges (like HiveMind) to interact with OVOS safely and predictably.

HiveMind: A Transport Protocol for Federated Voice Networks

HiveMind is a hierarchical transport protocol, defining clear rules for how messages are routed and how nodes communicate across a distributed network.

This means OVOS can operate as just one participant within a much larger HiveMind network or power that network entirely.

While HiveMind was originally designed to support OVOS Messages, it’s agent-agnostic, capable of transporting any kind of message for any kind of AI agent. HiveMind achieves this flexibility through HiveMind agent plugins, which act as adapters between HiveMind and the agent logic itself.

The reference plugin uses OVOS as the agent, but any agent can be integrated, as long as the plugin can consume and emit OVOS messages, translating them to whatever the target agent requires.

This architecture enables a distributed ecosystem where:

• Different devices can run different agents, each with its own intelligence and capabilities.
• All HiveMind satellites remain compatible and interconnected.
• You can use the OVOS audio stack and plugin ecosystem (for STT, TTS, wake words, etc.) with any non-OVOS agent, simply by writing a small HiveMind agent plugin wrapper.
• hivemind-a2a-agent-plugin will allow connecting hivemind voice satellites to any A2A agent

With the ongoing effort to formalize the OVOS Messagebus Protocol, HiveMind will soon align even more closely, officially carrying the same message definitions inside, effectively becoming an implementation of the OVOS Messagebus over the HiveMind protocol.

OVOS Plugin Manager: Interoperability by Design

At the core of OVOS’s modularity is the OVOS Plugin Manager, which allows every single OVOS component to be swapped out dynamically.

In this context, the “protocol” is a shared base class with a well-defined API that each plugin implements. This ensures that all plugins, no matter where they’re deployed, expose the same interface to consumers.

This approach allows the same plugin to run anywhere:

• as a standalone HTTP microservice (e.g., STT, TTS, translation, or persona server),
• locally on an OVOS device,
• under a HiveMind satellite, or
• as a service under HiveMind server.

It can even be embedded into other projects that want immediate access to OVOS’s plugin ecosystem without importing the full OVOS stack.

Each plugin is effectively an interoperability layer across technologies: reusable, self-contained, and designed to connect to anything.

Use only the pieces you need without losing compatibility.

The Big Picture: “Connect Anything to OVOS, and OVOS to Anything”

All these efforts — MCP, UTCP, A2A, HiveMind, the Messagebus Protocol, the Plugin Manager, and even Wyoming adapters — share one goal: to make OVOS a universal connector in the voice and AI ecosystem.

Whether you’re using local models, cloud APIs, or other assistants, OVOS aims to act as the interoperability layer that ties them together.

The result? An assistant that doesn’t lock you in, it opens you up to an entire universe of tools, models, and agents.

Work in Progress

These initiatives are all part of ongoing research and development. MCP, UTCP, and A2A are planned but not yet implemented, while HiveMind, the Messagebus documentation, and standalone OVOS microservices are active and evolving.

The roadmap is ambitious but clear: make OVOS the most interoperable open-source assistant platform in existence.

With support from the NGI0 Commons Fund, we’re investing in open standards, transparent protocols, and bridges that connect communities across the open-source AI and voice landscape.

If you care about open standards, agentic AI, and the freedom to connect anything to anything, we’d love your input and contributions. OVOS is not just building an assistant, it’s building the protocols of open intelligence.

Help Us Build Voice for Everyone

OpenVoiceOS is more than software, it’s a mission. If you believe voice assistants should be open, inclusive, and user-controlled, here’s how you can help:

• 💸 Donate: Help us fund development, infrastructure, and legal protection.
• 📣 Contribute Open Data: Share voice samples and transcriptions under open licenses.
• 🌍 Translate: Help make OVOS accessible in every language.

We're not building this for profit. We're building it for people. With your support, we can keep voice tech transparent, private, and community-owned.

👉 Support the project here

We’re excited to share some fantastic news — OpenVoiceOS (OVOS) has been selected to receive a grant from the NGI Zero Commons Fund!

This milestone represents a huge step forward for our mission to build an open, community-driven, and privacy-first voice assistant platform. With this support, we can accelerate our progress from beta to a first stable version under our OpenVoiceOS umbrella.

What is OpenVoiceOS?

OVOS is Europe’s open-source alternative to proprietary voice assistants. Built around transparency, modularity, and user freedom, OVOS lets you choose every component of your assistant — from wake word and speech recognition to text-to-speech, intent handling, and AI conversation modules — all while keeping full control over your data.

You can run OVOS entirely offline, on-premises, or in the cloud, making it suitable for:

• Smart homes and IoT devices
• Accessibility and assistive technologies
• Industrial and enterprise applications
• Research and educational environments

What the Grant Enables

With support from the NGI Zero Commons Fund, we’ll be able to:

• 💼 Hire our lead developer to deliver on the first stable roadmap
• 🧭 Improve onboarding and usability for non-technical users
• 🌍 Expand language support and stabilize platform components
• 📚 Enhance documentation for developers building skills and plug-ins

Real-World Impact

OVOS is already making a difference across Europe and beyond. It powers projects such as the Royal Dutch Visio Voicelab, bringing voice interaction to visually impaired users, as well as conversational assistants in nursing homes, manufacturing, and/ or multilingual AI initiatives.

This grant helps us strengthen that ecosystem — empowering developers, researchers, and users to shape the future of open, ethical voice technology.

Thank You ❤️

We want to express our gratitude to the NGI Zero Commons Fund, NLnet Foundation, and our incredible community of contributors, volunteers, and users. Your support makes it possible to keep building a voice assistant platform that prioritizes freedom, transparency, and privacy.

Together, we’re proving that open voice technology can be trustworthy, user-owned, and truly free.

Stay tuned for more updates as we move toward our full first stable release!

🔗 NLnet Announcement 🔗 NGI Zero Commons Fund 🔗 OpenVoiceOS Project Page

Help Us Build Voice for Everyone

If you believe that voice assistants should be open, inclusive, and user-controlled, we invite you to support OVOS:

• 💸 Donate: Your contributions help us pay for infrastructure, development, and legal protections.

• 📣 Contribute Open Data: Speech models need diverse, high-quality data. If you can share voice samples, transcripts, or datasets under open licenses, let's collaborate.

• 🌍 Help Translate: OVOS is global by nature. Translators make our platform accessible to more communities every day.

We're not building this for profit. We're building it for people. And with your help, we can ensure open voice has a future—transparent, private, and community-owned.

👉 Support the project here

We’re happy to announce that the OVOS (OpenVoiceOS) blog now supports a RSS / Atom feed at:

👉 https://blog.openvoiceos.org/feed.xml

This may look like a small technical change, but in reality it’s a big step forward — especially from the perspective of accessibility, interoperability, and empowering users. Below are a few reasons why we believe RSS is still relevant and why adding a feed is aligned with our vision.

Why RSS Still Matters in 2025

Yes, RSS is old technology, but that doesn’t mean it’s obsolete. Here are a few reasons it continues to deserve a place in the modern web ecosystem:

1. Decentralized content subscription RSS gives users control. Instead of being locked into one platform’s algorithm or interface, people can choose their own feed reader or aggregator. You subscribe once, and updates come to you, not the other way around.

2. Low overhead, simple format RSS / Atom feeds are lightweight XML documents. They don’t need heavy frameworks, JavaScript, or APIs. That means lower bandwidth, faster performance, and more compatibility with devices and assistive technologies.

3. Resilience & longevity Since RSS is an open standard, it’s not tied to any one company or service. If a blog or website changes its front-end, the feed often remains a stable outlet for updates. That robustness is valuable for archival, backup, and long-term content access.

4. Interoperability & portability RSS works across platforms, apps, and ecosystems. Want to surface blog posts in your smart home panel, or integrate them into your voice assistant? A feed makes that straightforward. You don’t have to reverse-engineer HTML pages or depend on ad-hoc APIs.

5. Accessibility-friendly This is especially important for OVOS and the intersection of voice, assistive tech, and open systems. Many feed readers are designed to work well with screen readers, text-to-speech tools, or simple “next item” navigation. Because RSS is structured, semantic, and minimal, assistive software can more reliably parse it.

Accessibility & Open Standards: Why We Care

At OVOS, our mission is to push toward more open, user-empowering voice and assistant systems. We believe accessibility is not an afterthought, it should be baked into every layer. Supporting an RSS feed is consistent with that philosophy:

• Equal access to content: Users who rely on assistive tech (screen readers, braille displays, voice-driven readers) should be able to consume blog updates just as easily as sighted users. Structured feeds help.
• Choice in how you consume: Whether you prefer to read in a browser, within a reader app, or have updates read out to you, RSS gives you options.
• Standards matter: Open standards promote interoperability and reduce handshake friction between systems. We’d rather everyone “speak RSS / Atom” than build brittle, custom bridges.
• Future-proofing: We want the OVOS blog to remain accessible and usable even if web frameworks change, hosting changes, or site redesigns happen. The feed is a thread through all of that.

How You Can Use the New Feed

Here are a few ideas to take advantage of the new RSS feed:

• Add it to your favorite news / feed reader (e.g. Feedly, Inoreader, Thunderbird) so new posts show up automatically.
• Use it in automation or scripting: For example, fetch new posts via a lightweight script, push them to your personal dashboard, or trigger voice notifications.
• Integrate with voice assistants: If you build a skill/plugin in OVOS or another system, you can parse the feed and let people ask “What’s new on the blog?” rather than scraping HTML.
• Share / mirror: You could mirror or aggregate OVOS content into your own blog or archive, thanks to the open nature of RSS.

Next Steps

• We’ll monitor for feedback, if the feed has issues, we’ll fix them.
• Consider expanding meta-data in feed items: more tags, categories, summaries, thumbnails, etc., to make it richer for readers and integrations.
• Encourage third-party projects in the OVOS ecosystem to use the feed for cross-linking, showing blog snippets in dashboards, or exposing blog summaries in voice UI.

If you come across any issues subscribing or using the feed, or have ideas for enhancements, please let us know.

Thank you for being part of the OVOS community! May your blog updates come to you, seamlessly and accessibly.

Help Us Build Voice for Everyone

OpenVoiceOS is more than software, it’s a mission. If you believe voice assistants should be open, inclusive, and user-controlled, here’s how you can help:

• 💸 Donate: Help us fund development, infrastructure, and legal protection.
• 📣 Contribute Open Data: Share voice samples and transcriptions under open licenses.
• 🌍 Translate: Help make OVOS accessible in every language.

We're not building this for profit. We're building it for people. With your support, we can keep voice tech transparent, private, and community-owned.

👉 Support the project here

The R36S handheld from AliExpress is usually marketed as a retro gaming device, but with a bit of tinkering it can also become a HiveMind-powered audio player, fully integrated with Home Assistant and Music Assistant 🎶.

This guide shows how I set up the hivemind-player on ArkOS and turned my device into a smart media endpoint.

Why HiveMind Player?

HiveMind Player lets you run the Open Voice OS (OVOS) audio stack as a service. Once configured, your R36S:

• Appears as a media player in Home Assistant 🏡
• Works seamlessly with Music Assistant 🎵
• Uses OpenVoiceOS for playback control (play, pause, next, etc.)
• Can handle TTS and system volume if you install the right plugins

See the HiveMind Media Player README for full technical details.

Step 1: Flash ArkOS

I used arkos4clone to install ArkOS on my R36 Ultra.

⚠️ Compatibility and initial steps may vary across clone devices, since there are many hardware variations. This guide applies to ArkOS-based firmware but assumes your handheld is already fully functional before starting.

👉 Always follow the specific instructions from your image provider, and check handhelds.wiki for the latest community documentation.

Once ArkOS is up:

• Connect to WiFi from the device menu
• Enable Remote Services
• SSH into the device from a computer

Step 2: Install uv

We’ll use uv for managing Python environments and dependencies:

curl -LsSf https://astral.sh/uv/install.sh | sh

Create a Python 3.10 virtual environment:

uv venv --python 3.10

Step 3: Install System Packages

ArkOS strips out many development headers, so we need to reinstall them.

Without these, I ran into some confusing build errors when trying to install plugins for volume control, including:

fatal error: limits.h: No such file or directory
fatal error: linux/limits.h: No such file or directory
fatal error: alsa/asoundlib.h: No such file or directory

These were resolved by reinstalling the right dev packages:

sudo apt install build-essential libffi-dev libssl-dev gcc libc6-dev
sudo apt install --reinstall libc6-dev linux-libc-dev libasound2-dev

Then install Python build tools:

uv pip install wheel

Step 4: Install HiveMind Player

Install the player with recommended extras (e.g., VLC, PHAL, OCP, TTS):

uv pip install git+https://github.com/JarbasHiveMind/hivemind-media-player[extras]

Step 5: Configure HiveMind Core

Create a config directory and set up the server.json:

mkdir -p ~/.config/hivemind-core/
nano ~/.config/hivemind-core/server.json

Example minimal configuration:

{
  "agent_protocol": {
    "module": "hivemind-player-agent-plugin",
    "hivemind-player-agent-plugin": {}
  },
  "network_protocol": {
    "hivemind-websocket-plugin": {
      "host": "0.0.0.0",
      "port": 5678
    },
    "hivemind-http-plugin": {
      "host": "0.0.0.0",
      "port": 5679
    }
  }
}

Step 6: Extra Plugins

You may want to install PHAL plugins for platform and hardware integration, or TTS plugins to use different voices

Currently the most useful is the ALSA plugin for system volume control:

uv pip install ovos-tts-plugin-piper ovos-phal-plugin-alsa ovos-PHAL-plugin-system

This makes volume adjustable via HiveMind / Home Assistant.

👉 PHAL is optional. Right now it’s only needed for volume control - and, as shown above, it required a lot of dev headers just to build. In the future, dedicated plugins may appear, for example to control the joystick LEDs on the R36 Ultra.

Step 7: Configure ovos-audio

HiveMind Player uses the OVOS audio stack for playback and TTS. The configuration lives in:

~/.config/mycroft/mycroft.conf

The main change required on ArkOS is adjusting the WAV playback command:

• By default, mycroft.conf uses paplay
• On ArkOS, this needs to be switched to aplay in order for TTS to work correctly

{
  "play_wav_cmdline": "aplay %1",
  "play_mp3_cmdline": "mpg123 %1",
  "play_ogg_cmdline": "ogg123 -q %1",

  "tts": {
    "module": "ovos-tts-plugin-piper",
    "ovos-tts-plugin-piper": {"voice": "alan-low"}
  },

  "Audio": {
    "backends": {
      "vlc": {
        "type": "vlc",
        "active": true,
        "initial_volume": 100,
        "low_volume": 50
      }
    }
  },

  "PHAL": {
    "ovos-PHAL-plugin-alsa": {
      "default_volume": 90
    },
    "ovos-PHAL-plugin-system": {
      "core_service": "hivemind-player.service",
      "ssh_service": "ssh.service",
      "sudo": true
    }
  }
}

• play_wav_cmdline → must be changed to aplay %1
• Audio → VLC is already available in ArkOS and can play nearly all streams you throw at it
• TTS → Default is ovos-tts-plugin-piper, but you can swap in any OVOS TTS plugin you prefer such as ovos-tts-plugin-server
• PHAL → system plugin needs to be adjusted in order to use the correct service names

NOTE: in arkOS sudo does not require password, therefore ovos-PHAL-plugin-system should work out of the box

Step 8: Set Up Permissions

HiveMind operates on a deny-all policy by default: every message type must be explicitly allowed for clients.

First, create a client identity:

hivemind-core add-client

This gives you an Access Key and Password.

Next, allow the minimum messages needed for playback and TTS. Replace <NODE_ID> with the client’s Node ID:

# Basic audio / TTS
hivemind-core allow-msg "speak" <NODE_ID>
hivemind-core allow-msg "mycroft.audio.is_alive" <NODE_ID>
hivemind-core allow-msg "mycroft.audio.is_ready" <NODE_ID>
hivemind-core allow-msg "mycroft.audio.speak.status" <NODE_ID>
hivemind-core allow-msg "mycroft.stop" <NODE_ID>

# Common Play (playback control)
hivemind-core allow-msg "ovos.common_play.play" <NODE_ID>
hivemind-core allow-msg "ovos.common_play.pause" <NODE_ID>
hivemind-core allow-msg "ovos.common_play.resume" <NODE_ID>
hivemind-core allow-msg "ovos.common_play.stop" <NODE_ID>
hivemind-core allow-msg "ovos.common_play.next" <NODE_ID>
hivemind-core allow-msg "ovos.common_play.previous" <NODE_ID>
hivemind-core allow-msg "ovos.common_play.player.status" <NODE_ID>
hivemind-core allow-msg "ovos.common_play.track_info" <NODE_ID>

# Optional: volume (PHAL ALSA plugin)
hivemind-core allow-msg "mycroft.volume.get" <NODE_ID>
hivemind-core allow-msg "mycroft.volume.set" <NODE_ID>
hivemind-core allow-msg "mycroft.volume.increase" <NODE_ID>
hivemind-core allow-msg "mycroft.volume.decrease" <NODE_ID>
hivemind-core allow-msg "mycroft.volume.mute" <NODE_ID>
hivemind-core allow-msg "mycroft.volume.unmute" <NODE_ID>

# Optional: SSH, Reboot and Shutdown (PHAL system plugin)
hivemind-core allow-msg "system.ssh.status" <NODE_ID>
hivemind-core allow-msg "system.ssh.enable" <NODE_ID>
hivemind-core allow-msg "system.ssh.disable" <NODE_ID>
hivemind-core allow-msg "system.reboot" <NODE_ID>
hivemind-core allow-msg "system.shutdown" <NODE_ID>

Step 9: Create a System Service

To keep HiveMind Player running in the background, add a systemd user service:

mkdir -p ~/.config/systemd/user/
nano ~/.config/systemd/user/hivemind-player.service

Paste this:

[Unit]
Description=HiveMind Player
After=network.target

[Service]
WorkingDirectory=/home/ark
ExecStart=/home/ark/.venv/bin/python /home/ark/.venv/bin/hivemind-core listen
Restart=on-failure

[Install]
WantedBy=default.target

Then enable and start it:

systemctl --user daemon-reload
systemctl --user enable hivemind-player.service --now
systemctl --user status hivemind-player.service

Step 10: Optional - Install tailscale for remote access

A problem we have with the R36S is that it changes IP address on every boot and randomizes its MAC address; to work around this we could try to assign a static IP address but since this is a handheld and will often be on the move, why not use a VPN?

tailscale is free and painless to install

curl -fsSL https://tailscale.com/install.sh | sh
sudo systemctl enable tailscaled
sudo tailscale login
sudo systemctl start tailscaled
sudo systemctl status tailscaled

Now we have a static ip address AND we can access the handheld remotely

Step 11: Integrate with Home Assistant

With the hivemind-homeassistant integration installed, your R36 Ultra shows up as a media player inside Home Assistant.

In Home Assistant, the TTS setup also makes the device available as a notify entity, so you can send text notifications and have them spoken on your R36 Ultra:

service: notify.hivemind_player
data:
  message: "Dinner is ready!"

Combine this with Music Assistant and suddenly your retro handheld doubles as a WiFi speaker you can control from your smart home dashboard.

Wrap-Up

That’s it! My R36 Ultra, originally built for emulation, now runs HiveMind Player on ArkOS and integrates seamlessly with my smart home setup.

• HiveMind manages the player backend
• Home Assistant discovers it
• Music Assistant lets me browse and stream to it
• ovos-audio makes it flexible for both playback and TTS
• Optional PHAL plugins give extra control (volume now, LEDs in the future)
• Permissions ensure only trusted clients can control it

A fun way to repurpose cheap handheld hardware into a smart speaker alternative! 🚀

Help Us Build Voice for Everyone

OpenVoiceOS is more than software, it’s a mission. If you believe voice assistants should be open, inclusive, and user-controlled, here’s how you can help:

• 💸 Donate: Help us fund development, infrastructure, and legal protection.
• 📣 Contribute Open Data: Share voice samples and transcriptions under open licenses.
• 🌍 Translate: Help make OVOS accessible in every language.

We're not building this for profit. We're building it for people. With your support, we can keep voice tech transparent, private, and community-owned.

👉 Support the project here

Today marks a significant step forward in the OpenVoiceOS journey with the official adoption of phoonnx as our primary Text-to-Speech (TTS) framework.

This new generation of voices is not just about quality; it's about consistency, efficiency, and fulfilling our mission for truly open, offline-ready voice assistants across the globe.

New Language: Introducing Basque!

Building on our previous work on Making Synthetic Voices From Scratch and our successful Arabic TTS Collaboration, we are excited to announce a new milestone in our language support: the addition of new voices for Basque (eu-ES)!

This includes both the male voice (Miro) and female voice (Dii), furthering our mission to support even low-resource languages that lack open, high-quality TTS options.

Previously only a robotic female voice was available, via the AhoTTS plugin made in collaboration with ILENIA.

Hear the results: Examples of the new Basque Open-Source Voices.

A Unified Voice for a Global Brand

As OpenVoiceOS expands to more languages and more devices, a crucial need has emerged: a cohesive brand identity conveyed through voice. We need a core set of voices, a standard male and female persona, that sounds the same, professional, and recognizable no matter where you are in the world or which language you are speaking.

This consistency is vital. Imagine installing OpenVoiceOS in Lisbon, Berlin, or Seattle, the voice should be instantly familiar. This is the power of a unified voice, creating a seamless and trustworthy user experience globally.

We are proud to share that TigreGotico has been instrumental in making this vision a reality. They are not only developing the core phoonnx engine but are also actively contributing to open datasets and training the default, multi-lingual OVOS voices. This internal collaboration accelerates development and ensures our voices are aligned with the open-source spirit of our platform.

The phoonnx Advantage: A Flexible TTS Ecosystem

phoonnx is more than just an inference tool; it is a complete training and inference framework built on the robust VITS architecture. This dual capability allows us to rapidly prototype, train, and deploy high-quality voices.

A key to this flexibility is the ability to support diverse phonemizers. A phonemizer (or G2P - Grapheme-to-Phoneme model) converts written text into the sequence of sound units (phonemes) the TTS model speaks. Different languages may require different, specialized phonemizers for accurate speech.

• eSpeak Compatibility: A core feature is that phoonnx models are fully compatible with the popular Piper TTS engine's runtime, provided they were trained using the widely available eSpeak phonemizer. This ensures easy deployment within the existing OVOS ecosystem and third party projects like Home Assistant.
• Custom Phonemizer Support: The framework is not limited to eSpeak. For example, we are excited to note that the high-quality Galician models developed by Proxecto Nós using the Cotovia phonemizer are fully compatible and can be used with the phoonnx pipeline.

This flexibility allows us to integrate and benefit from the work of other open-source projects. In fact, for inference, phoonnx can successfully use models originally trained by other projects, including Coqui, Mimic3, and Piper, solidifying its role as a universal TTS deployment tool.

Teasing the Future: Next-Gen G2P Models

Looking ahead, we are constantly working to improve G2P accuracy, especially for low-resource languages. We are currently developing and testing next-generation G2P models based on the powerful ByT5 architecture. These transformer-based models promise to deliver more accurate and robust phonemization across a wider range of languages.

You can follow their development here: G2P Models Collection.

In the near future a dedicated OVOS TTS plugin will be created for phoonnx and made the default for OpenVoiceOS, replacing the previous plugins: ovos-tts-plugin-piper and ovos-tts-plugin-nos.

In the meantime you can try the new voices via the existing plugin ovos-tts-plugin-piper

All you need to do is pass the model urls under mycroft.conf

  "tts": {
    "module": "ovos-tts-plugin-piper",
    "ovos-tts-plugin-piper": {
      "model": "https://huggingface.co/OpenVoiceOS/phoonnx_eu-ES_miro_espeak/resolve/main/miro_eu-ES.onnx",
      "model_config": "https://huggingface.co/OpenVoiceOS/phoonnx_eu-ES_miro_espeak/resolve/main/miro_eu-ES.piper.json"
    }
  }

Progress Report: Available Languages

The collective work of the OpenVoiceOS and TigreGotico teams has resulted in a rapidly expanding library of open-source TTS models.

Currently Supported Languages:

• Arabic
• Basque
• Dutch
• English (US/GB)
• French
• German
• Italian
• Portuguese (Brazil/Portugal)
• Spanish

Get Involved and Find the Models

We invite the community to explore and utilize these new resources. Your feedback is crucial to improving voice quality and expanding language coverage.

Help Us Build Voice for Everyone

OpenVoiceOS is more than software, it’s a mission. If you believe voice assistants should be open, inclusive, and user-controlled, here’s how you can help:

• 💸 Donate: Help us fund development, infrastructure, and legal protection.
• 📣 Contribute Open Data: Share voice samples and transcriptions under open licenses.
• 🌍 Translate: Help make OVOS accessible in every language.

We're not building this for profit. We're building it for people. With your support, we can keep voice tech transparent, private, and community-owned.

👉 Support the project here

As the External Collaborations Lead at Planet Blind Tech, I recently had the privilege of working closely with OpenVoiceOS on a groundbreaking project: training an open-source Arabic voice. This effort was far more than a technical experiment; it was a meaningful step toward digital inclusion for blind and visually impaired communities.

I first encountered their project while exploring the intersections between assistive technology and speech synthesis. It was clear that our missions aligned. Their dedication to creating open voice technologies resonated with our own pursuit of accessible tools for blind users. The chance to contribute to an Arabic TTS (Text-to-Speech) voice felt like the bridge we had long been waiting for.

Our team’s role focused on two essential tasks: gathering datasets and testing the resulting models. The process was not without its hurdles. The initial dataset we worked with fell short of the desired quality. Yet, the patience, openness, and technical guidance from our partners encouraged us to refine our approach. Together, we introduced a more robust dataset and trained a model with Phoonnx and the eSpeak phonemizer, which produced results that genuinely reflected the richness of the Arabic language.

Hear the results: Examples of the new Arabic Open-Source Voices.

The impact of this work is already tangible. An Arabic open-source voice is not just another model, it is a lifeline for blind individuals who rely on screen readers and accessible applications. For the first time, many users can envision a future where they are not tied to proprietary voices or limited to languages that do not fully capture their identity. This achievement lowers barriers, empowers developers to integrate the voice into assistive tools, and above all, gives blind users a sense of agency.

What began as a collaboration to create a voice has evolved into something larger: a demonstration of what open technology can mean for inclusion. For our community, this project is more than sound, it is dignity, independence, and opportunity. And for me personally, it stands as a reminder of the transformative power of working together across communities to ensure no voice, and no person, is left unheard.

You can find the collected datasets and trained models on huggingface:

• Arabic TTS Model - Dii
• Arabic TTS Model - Miro
• Arabic TTS Model - Miro (V2)
• Arabic G2P Dataset
• Synthetic Arabic TTS Training Data - Miro with Diacritics
• Synthetic Arabic TTS Training Data - Dii with Diacritics

Help Us Build Voice for Everyone

OpenVoiceOS is more than software, it’s a mission. If you believe voice assistants should be open, inclusive, and user-controlled, here’s how you can help:

• 💸 Donate: Help us fund development, infrastructure, and legal protection.
• 📣 Contribute Open Data: Share voice samples and transcriptions under open licenses.
• 🌍 Translate: Help make OVOS accessible in every language.

We're not building this for profit. We're building it for people. With your support, we can keep voice tech transparent, private, and community-owned.

👉 Support the project here

In the world of open-source smart homes, some things just click. When you let Home Assistant handle the automation and let OVOS (Open Voice OS) handle the voice, you get a powerful partnership where each project shines. It’s a perfect synergy: one is the undisputed champion of home automation, and the other is a flexible, private powerhouse for voice interaction.

Home Assistant excels at orchestrating your devices and routines, while OVOS provides unparalleled flexibility and privacy in voice interactions. Together, they create a system that's not only robust but also truly yours.

Let's explore how you can bring these two together to create a truly magical smart home experience.

Give Home Assistant an OVOS-Powered Voice

The most direct way to get started is to enhance Home Assistant's built-in voice capabilities with the specialized tools from the OVOS ecosystem. Our main goal is to make OVOS's powerful tools accessible to as many people as possible.

To achieve this, we've developed dedicated Wyoming integrations that act as bridges, allowing any OVOS Text-to-Speech (TTS), Speech-to-Text (STT), or Wakeword plugin to be exposed to Home Assistant.

This means you're not limited to a few options; you gain immediate access to the entire rich ecosystem of OVOS voice plugins, bringing a vast array of languages, voices, and recognition models directly into your Home Assistant setup.

• Wyoming OVOS STT: Convert spoken commands into text for Home Assistant to understand.
• Wyoming OVOS TTS: Enable Home Assistant to speak responses using OVOS's diverse voice options.
• Wyoming OVOS Wakeword: Integrate custom wakewords, allowing your Home Assistant setup to respond only when it hears your chosen trigger phrase.

The OVOS Wyoming Docker project makes getting these services up and running a breeze.

Plugin Highlights: Multi-language TTS powered by ILENIA

For us, accessibility is key. That includes language accessibility. We're proud that this integration allows us to bring high-quality, publicly funded voices from projects like ILENIA to a wider audience. Now, Home Assistant users can easily access fantastic, natural-sounding voices for languages like Catalan and Galician.

• Matxa TTS for Catalan: The ovos-tts-plugin-matxa-multispeaker-cat provides multi-speaker text-to-speech capabilities for the Catalan language.
• NosTTS for Galician: The ovos-tts-plugin-nos offers robust text-to-speech in Galician.

It’s a great example of how open collaboration benefits everyone.

Setting up Wyoming Services in Home Assistant:

When configuring Wyoming services in Home Assistant, you'll typically refer to the official Home Assistant documentation. This process usually involves simply entering the IP address of your Docker container (or the host running your OVOS Wyoming services) into the Home Assistant web interface.

Let OVOS Be the Brains of the Conversation

Want to take it a step further? You can set up OVOS as a full-fledged conversational agent for Home Assistant using the Ollama integration.

In this setup, Home Assistant passes the user's text to the ovos-persona-server. OVOS then figures out what you want and tells Home Assistant what to answer. It’s like hiring a brilliant conversationalist to augment your smart home interactions.

Here’s the cool part: because ovos-persona-server uses Ollama-compatible endpoints, you can connect it to any app that supports the Ollama or OpenAI APIs. The possibilities are huge!

OVOS with the Voice Pe

Everyone is talking about Home Assistant Voice Preview Edition, a dedicated hardware device for voice control. If you own one, you can now easily integrate it with everything discussed so far.

Welcome Your OVOS Devices into Home Assistant with HiveMind

If you have dedicated OVOS devices, the HiveMind HomeAssistant project is where the real magic happens. This integration makes your OVOS devices show up as native entities in Home Assistant, giving you a beautiful, unified control panel.

Setting up HiveMind Integration:

To integrate your OVOS devices via HiveMind, you'll typically add the HiveMind integration in Home Assistant. This involves providing connection details such as a name for the integration, an access_key, password, site_id, host (IP address or hostname of your HiveMind server), and the port (defaulting to 5678). You may also have options to allow_self_signed certificates or enable legacy_audio depending on your setup.

Exposed Controls for OVOS Devices:

Once integrated, HiveMind exposes a comprehensive set of controls for your OVOS devices directly within Home Assistant. This allows you to manage various aspects of your OVOS device from the Home Assistant UI, including:

• Changing the Listening Mode (e.g., wakeword, always listening)
• Microphone Mute toggle
• OCP Player status and controls
• Actions like Reboot Device, Restart OVOS, and Shutdown Device
• Toggling Sleep Mode and SSH Service
• Manually Start Listening or Stop listening
• Controlling volume level

Notifications Integration:

HiveMind also enables your OVOS devices to function as notification targets within Home Assistant. This means you can configure Home Assistant automations to send spoken notifications directly to your OVOS devices, allowing them to "speak" alerts, reminders, or any other information you configure. This is exposed as a "Speak" notifier entity in Home Assistant.

Media Player and Music Assistant Integration:

A fantastic feature of HiveMind integration is that your OVOS devices will show up as standard media players within Home Assistant. This allows you to control media playback on your OVOS devices directly from Home Assistant's media player interface. Furthermore, this integration extends to services like Music Assistant, enabling you to stream music and other audio content from Music Assistant through your OVOS devices, making them a seamless part of your whole-home audio system.

Give OVOS the Keys to the Kingdom

Finally, with the fantastic Skill HomeAssistant from community member mikejgray, you can give OVOS direct control over Home Assistant.

Install this skill, and your OVOS device can now command your smart home. Just say, "Hey Mycroft, turn on the living room lights," and watch the magic happen. It’s the classic voice assistant experience, but fully private, customizable, and powered by two best-in-class open-source projects.

The Perfect Match

When you let OVOS do the talking and Home Assistant do the automating, you get the best of both worlds. It’s a flexible, powerful, and fun combination that lets you build a smart home that is truly your own.

A Note on This Early Preview Release:

We're incredibly excited to share this integration with you! Please keep in mind that this is an early preview release and is still under active development. While it's functional and powerful, it hasn't undergone extensive testing and may have rough edges. We're actively working to refine it, and your feedback is invaluable!

If you encounter any pain points or have ideas for improvements, please consider opening an issue or, even better, a Pull Request on our GitHub repositories. Your contributions help us make this even better for everyone. Thanks for being an early adopter and helping us shape the future of open-source voice!

Help Us Build Voice for Everyone

OpenVoiceOS is more than software, it’s a mission. If you believe voice assistants should be open, inclusive, and user-controlled, here’s how you can help:

• 💸 Donate: Help us fund development, infrastructure, and legal protection.
• 📣 Contribute Open Data: Share voice samples and transcriptions under open licenses.
• 🌍 Translate: Help make OVOS accessible in every language.

We're not building this for profit. We're building it for people. With your support, we can keep voice tech transparent, private, and community-owned.

👉 Support the project here

Daily-driver edition: practical, speedy, and just cheeky enough 😏.

OVOS = Open Voice OS.

The demo shows our smart mirror flipping personas on command—Friendly, Snobby, Smarty Pants—while everything runs locally. Below is the daily-driver recipe we actually use: classic skills stay in charge, personas jump in when it’s chat time, and MagicMirror² handles the visuals. No devices were harmed. ☁️❌

🎥 Watch: https://www.youtube.com/watch?v=DDkEbAySH0I

Why personas (and why this layout)?

In OVOS, a persona is a runtime-swappable reasoning preset. It can route a question to an LLM, change tone/verbosity, and gracefully handle open-ended chatter. This layout keeps your high-confidence skills first (timers, weather, music, home control), then lets the persona shine for the fuzzy stuff. Best of both worlds. ✨

TL;DR (copy/paste speed-run)

1. Install OVOS with the ovos-installer TUI, select alpha channel, and do NOT enable GUI (MagicMirror² is the face).
2. In mycroft.conf (e.g., ~/.config/mycroft/mycroft.conf or /etc/mycroft/mycroft.conf), add ovos-persona-pipeline-plugin-high after your high matchers.
3. Drop the persona JSON files below (Local LLM, Friendly, Snobby, Smarty Pants) and run Ollama for the model.
4. Set up MagicMirror² with MMM-ShareToMirror + MMM-ovos-wakeword and the OVOS skill ovos-skill-share-to-mirror.
5. Say “Switch to Local LLM persona,” and enjoy your mirror’s new mood. ☕️

1) Install OVOS via the TUI (choose alpha & do NOT enable GUI)

sudo sh -c "$(curl -fsSL https://raw.githubusercontent.com/OpenVoiceOS/ovos-installer/main/installer.sh)"

Inside the TUI:

• Channel: pick Alpha (latest persona goodness)
• Method: virtualenv (or containers)
• Profile: OVOS
• Features: enable Skills ✅ and do NOT enable GUI ❌ (MagicMirror² provides visuals)

Keep your config path handy: ~/.config/mycroft/mycroft.conf (user) or /etc/mycroft/mycroft.conf (system).

2) Add ovos-persona to today’s pipeline (daily-driver)

Edit your config at ~/.config/mycroft/mycroft.conf or /etc/mycroft/mycroft.conf. Insert persona after the high-confidence matchers:

{
  "intents": {
    "pipeline": [
      "ovos-stop-pipeline-plugin-high",
      "ovos-converse-pipeline-plugin",
      "ovos-ocp-pipeline-plugin-high",
      "ovos-padatious-pipeline-plugin-high",
      "ovos-adapt-pipeline-plugin-high",
      "ovos-m2v-pipeline-high",

      "ovos-persona-pipeline-plugin-high",

      "ovos-ocp-pipeline-plugin-medium",
      "ovos-fallback-pipeline-plugin-high",
      "ovos-stop-pipeline-plugin-medium",
      "ovos-adapt-pipeline-plugin-medium",
      "ovos-fallback-pipeline-plugin-medium",
      "ovos-fallback-pipeline-plugin-low"
    ]
  }
}

Why here? Skills get first crack at clear commands. Persona handles open-ended “hmm, let’s think” questions—without stepping on your timers and lights. 🔦

3) Personas (drop these into ~/.config/ovos_persona/)

All four personas use a local LLM via Ollama’s OpenAI-style /v1 API. Adjust model to taste (gemma3:4b is a great default).

local-llm.json — base persona

{
  "name": "Local LLM",
  "solvers": ["ovos-solver-openai-plugin"],
  "ovos-solver-openai-plugin": {
    "api_url": "http://127.0.0.1:11434/v1",
    "key": "ollama",
    "model": "gemma3:4b",
    "system_prompt": "helpful, witty, concise; prefers practical answers.",
    "temperature": 0.6
  }
}

friendly.json

{
  "name": "Friendly",
  "solvers": ["ovos-solver-openai-plugin"],
  "ovos-solver-openai-plugin": {
    "api_url": "http://127.0.0.1:11434/v1",
    "key": "ollama",
    "model": "gemma3:4b",
    "system_prompt": "kind, upbeat, plain language, one actionable next step; no emojis.",
    "temperature": 0.7
  }
}

snobby.json

{
  "name": "Snobby",
  "solvers": ["ovos-solver-openai-plugin"],
  "ovos-solver-openai-plugin": {
    "api_url": "http://127.0.0.1:11434/v1",
    "key": "ollama",
    "model": "gemma3:4b",
    "system_prompt": "precise, mildly sardonic librarian; terse and technically correct; no emojis.",
    "temperature": 0.5
  }
}

smarty-pants.json

{
  "name": "Smarty Pants",
  "solvers": ["ovos-solver-openai-plugin"],
  "ovos-solver-openai-plugin": {
    "api_url": "http://127.0.0.1:11434/v1",
    "key": "ollama",
    "model": "gemma3:4b",
    "system_prompt": "clever explainer; tiny examples; 1–2 sentences per idea; playful but clear; no fluff.",
    "temperature": 0.65
  }
}

🎭 Note on “vibe” vs model

Even with the same persona file, different models behave differently:

• gemma3:4b – friendly, concise; great default on Pi/mini-PC.
• qwen2.5:1.5b – very small & literal; bump temperature slightly if it feels too dry.
• llama3.1:8b – more capable but chattier; lower temperature & max_tokens to keep replies snappy.

Think of the persona JSON as the style guide, and the model as the actor—casting changes the performance. 🎬

4) Run a local model with Ollama

curl -fsSL https://ollama.com/install.sh | sh
ollama pull gemma3:4b
ollama serve &                # http://127.0.0.1:11434/v1
curl -s http://127.0.0.1:11434/v1/models | jq .

5) Install MagicMirror²

# prerequisites: Node 18+, git
git clone https://github.com/MagicMirrorOrg/MagicMirror ~/MagicMirror
cd ~/MagicMirror
node --run install-mm
cp config/config.js.sample config/config.js
# start on the local display
node --run start
# or as a web server:
# node --run server

If you run server-only, set address: "0.0.0.0" and add your LAN to ipWhitelist in config/config.js.

6) Add MMM-ShareToMirror + ovos-skill-share-to-mirror

• Module: https://github.com/smartgic/MMM-ShareToMirror
• Skill: https://github.com/smartgic/ovos-skill-share-to-mirror

Install the module

cd ~/MagicMirror/modules
git clone https://github.com/smartgic/MMM-ShareToMirror.git
cd MMM-ShareToMirror && npm install

Add to ~/MagicMirror/config/config.js:

{
  module: "MMM-ShareToMirror",
  position: "bottom_center",
  config: {
    port: 8570,
    https: { enabled: false },
    invisible: true,
    overlay: {
      width: "70vw",
      maxWidth: "1280px",
      aspectRatio: "16 / 9",
      zIndex: 9999,
      borderRadius: "16px",
      boxShadow: "0 10px 36px rgba(0,0,0,.5)"
    },
    caption: { enabled: false, lang: "en" },
    quality: { target: "auto", lock: false }
  }
}

Install the OVOS skill (pip method)

pip install "git+https://github.com/smartgic/ovos-skill-share-to-mirror.git"

Create skill settings at ~/.config/mycroft/skills/ovos-skill-share-to-mirror.smartgic/settings.json:

{
  "base_url": "http://<MIRROR_IP>:8570",
  "verify_ssl": false,
  "request_timeout": 6,
  "caption_enabled": false,
  "caption_lang": "en",
  "quality_target": "auto",
  "quality_lock": false,
  "search_backend": "yt_dlp",
  "youtube_api_key": ""
}

Restart OVOS services so the skill gets picked up. Now you can say: “Play a video about espresso on the mirror.” …and the skill will drive the MMM-ShareToMirror overlay.

More handy intents for this skill

• “Play <query> on the mirror.” — search + play
• “Pause the mirror video.” / “Resume the mirror video.”
• “Stop the mirror video.”
• “Show captions on the mirror.” / “Hide captions on the mirror.”
• “Set mirror quality to high/auto/low.”
• “Open this YouTube link on the mirror.” (if used with a URL or clipboard helper)
• “Close the mirror overlay.” (hides the player)

7) Add MMM-ovos-wakeword (+ OVOS side ping)

• Module: https://github.com/smartgic/MMM-ovos-wakeword

Install the module

cd ~/MagicMirror/modules
git clone https://github.com/smartgic/MMM-ovos-wakeword.git

Add to ~/MagicMirror/config/config.js (and allow your LAN):

let config = {
  address: "0.0.0.0",
  port: 8080,
  ipWhitelist: ["127.0.0.1","::1","::ffff:192.168.1.1/24"],

  modules: [
    // ... other modules ...
    {
      module: "MMM-ovos-wakeword",
      position: "lower_third",
      config: {
        title: "Open Voice OS",
        apiKey: "CHANGE-ME-TO-A-RANDOM-STRING",
        maxMessages: 1,
        opacity: 0.5
      }
    }
  ]
}

Install the OVOS PHAL plugin to send the wake cue

pip install ovos-phal-plugin-mm-wakeword

Create ~/.config/OpenVoiceOS/ovos-phal-plugin-mm-wakeword.json:

{
  "url": "http://<MIRROR_IP>:8080",
  "key": "CHANGE-ME-TO-A-RANDOM-STRING",
  "message": "Listening...",
  "timeout": 10,
  "verify": false
}

Restart OVOS (systemctl --user restart ovos). Say your wake word — the mirror flashes “Listening…” then fades. ✨

8) Use it (talk to your mirror like it’s totally normal)

• “Switch to Local LLM persona.”
• “Switch to Friendly.”
• “Talk to Snobby about pour-over coffee.”
• “Smarty Pants, explain Kubernetes like I’m five.”
• “Play lo-fi beats on the mirror.”
• “List personas.”

If your mirror starts giving life advice, that’s on you. 😇

That’s it—your daily-driver setup is ready. Skills stay crisp, personas bring the charm, and your mirror finally has the personality it deserves. Now go ask it for a pep talk before your next meeting. 💪🪞

Over the past five years, I’ve visited many people with disabilities in their homes and witnessed firsthand how much effort it can take to control everyday things like lights, heating, doors, curtains, and appliances. Often, this leads to less comfort than what’s technically possible. Giving people access to voice-activated home automation isn't just convenient—it offers them greater independence, comfort, and peace of mind.

Such a system typically consists of two core components: a home automation gateway and a voice assistant. OVOS (Open Voice OS) is a voice-first assistant that integrates seamlessly with home automation systems. Its full focus on voice means that every part of the system—from wakeword to intent—is designed with spoken interaction in mind.

With OVOS, I can fully customize and control intents for things like switching on lights, playing music, or interacting with an AI assistant. That level of control is often missing in commercial systems. Sometimes, when you ask them to close the curtains, they might suggest where to buy new ones instead.

OVOS and Hivemind filling Real Needs

I'm using an OVOS server with Hivemind satellites, which allows me to adapt the system to virtually any use case. These lightweight, low-cost satellites make it feasible to have a voice assistant in every room. What’s more, I can easily customize the enclosures to suit specific situations—like fitting them into a bathroom, or attaching one to a wheelchair. Thanks to their low power consumption, the satellites can even be powered directly from a wheelchair battery.

Looking ahead, the next step is integrating a personal AI assistant directly into the voice assistant. This enables a private, fully offline solution—something that’s becoming increasingly important for privacy, reliability, and autonomy.

How did I built a Smarter Living with OVOS, Hivemind, and Raspberry Pi Satellites

In this showcase, I’ve built a basic voice setup using Open Voice OS (OVOS) and Hivemind. The OVOS server runs on a compact Intel NUC with a 5th-gen i5 processor. It hosts both the OVOS core and a Generative AI model (Ollama running Gemma3:1B), which enables offline voice control and (some) intelligence and context-aware responses. By linking OVOS to my Homey gateway, I can control lighting, audio, and various smart devices with natural speech.

To expand voice coverage throughout the house, I added Raspberry Pi Zero 2W units as satellites. These low-power devices use local voice activation (VAD) to detect the wakeword ("Hey Mycroft"). Once triggered, they record the spoken command and forward the audio to the Hivemind listener on the OVOS server. Hivemind then routes the audio to OVOS, which parses the utterance and executes the appropriate intent—whether it’s starting a radio stream, sending a message to the AI assistant, or toggling a device via the Homey API.

While OVOS and Hivemind are still evolving, this setup already proves itself in real-world use. It’s stable enough for friendly testing and flexible enough to grow with future needs.

Conclusion

OVOS has key features for controlling the house:

• fine control on intents to enable predictive outcomes
• satellite architecture for use case flexibility
• [future] Integrated with local or private GenAI

More links

• 3D drawings
• PCB drawings
• OVOS technical manual
• Hivemind documentation

Help Us Build Voice for Everyone

If you believe that voice assistants should be open, inclusive, and user-controlled, we invite you to support OVOS:

• 💸 Donate: Your contributions help us pay for infrastructure, development, and legal protections.

• 📣 Contribute Open Data: Speech models need diverse, high-quality data. If you can share voice samples, transcripts, or datasets under open licenses, let's collaborate.

• 🌍 Help Translate: OVOS is global by nature. Translators make our platform accessible to more communities every day.

We're not building this for profit. We're building it for people. And with your help, we can ensure open voice has a future—transparent, private, and community-owned.

👉 Support the project here

Ever had your OpenVoiceOS assistant respond with a blank stare, or worse, confidently say something that had absolutely nothing to do with what you said? We've all been there. It’s like trying to reason with a sleep-deprived parrot: part amusing, mostly frustrating.

Well, get ready to reclaim your sanity. We're excited to introduce a new member of the OVOS ecosystem: the OVOS Transcription Validator Plugin, your new favorite gatekeeper for STT nonsense.

What's the Point?

Picture this: your assistant is a club bouncer for utterances. Every spoken phrase gets checked before it’s allowed into the VIP lounge of “Intent Handling.” If your transcription is incoherent, incomplete, or simply unhinged, the bouncer boots it right back to the sidewalk. No more "Potatoes stop green light now yes" turning on your kitchen lights. No more "Play the next song, but make it sound like a cat" confusing your music library.

This plugin ensures only sane, well-formed inputs move forward, drastically improving the assistant’s overall reliability.

Okay, But How?

Magic. Kidding. It’s just LLMs doing what they do best, judging you silently.

Here’s what actually happens:

1. You speak; the STT engine transcribes.
2. The plugin grabs the result and the language info.
3. It sends that to your configured LLM (local Ollama, OpenAI-compatible API, you name it).
4. The LLM replies: “Yup, that’s language” or “Nope, that's verbal spaghetti”.
5. If rejected, the utterance is dropped before it causes downstream chaos (you can even play a polite error beep or ask the user to repeat themselves).

LLMs for This? Really?

We hear you. It is a bit like using a sledgehammer to swat a fly. Validating a sentence isn’t rocket science, but it turns out rocket science is cheap and locally available now.

Yes, Large Language Models are arguably overkill for checking if "play music" is a coherent command. But the results are strong, and let’s face it: you’re probably already running an LLM somewhere just to decide which emoji to use.

Still, we acknowledge the irony. In an age of bloated "AI agents" managing other agents, this plugin fits right in. Yo dawg, I heard you like agents, so we added an agent to your agent to decide if it’s allowed to answer.

If you’re looking for lighter-weight alternatives, we’ve considered adding traditional rule-based validators too. But for now, if you’ve got the cycles, why not let the LLM earn its keep?

Get Started: Stop the Gibberish at the Gate

Want in? Getting started is easy. Visit the GitHub repo for installation instructions and configuration tips.

With the OVOS Transcription Validator Plugin, your assistant will stop mistaking scrambled speech for commands, and you’ll stop yelling at your microwave because it thought you said “set timer for forty giraffes.”

So, go forth and chat with your OpenVoiceOS assistant with renewed confidence! With the OVOS Transcription Validator Plugin, your conversations will be clearer, your commands more precise, and those moments of "What on Earth did I just say?!" will become a distant, funny memory.

Help Us Build Voice for Everyone

OpenVoiceOS is more than software, it’s a mission. If you believe voice assistants should be open, inclusive, and user-controlled, here’s how you can help:

• 💸 Donate: Help us fund development, infrastructure, and legal protection.
• 📣 Contribute Open Data: Share voice samples and transcriptions under open licenses.
• 🌍 Translate: Help make OVOS accessible in every language.

We're not building this for profit. We're building it for people. With your support, we can keep voice tech transparent, private, and community-owned.

👉 Support the project here

What’s the problem?

Creating a voice for a text-to-speech (TTS) system usually requires a real person to spend hours recording audio. That’s expensive, time-consuming, and in many languages or accents, the voices just don’t exist at all, especially for open-source or offline use.

What did we do?

We developed a technique that allows us to create synthetic voices completely from scratch, even if we don’t have recordings from a real person. These voices:

• Work offline, even on small devices like a Raspberry Pi,
• Can speak any language, if there’s a good donor system available,
• Are fully customizable in sound and tone.

How does it work?

1. Start with an existing voice - We use an existing TTS voice (from any source) to generate lots of fake speech and text pairs.

2. Transform it into a new voice - We apply a special voice conversion process to change the sound of the voice to something new, like a different gender, age, or accent.

3. Train a compact model - With this synthetic data, we train a new voice model that sounds natural, speaks fluently, and runs entirely offline.

Why is this special?

• We can create a new voice without needing anyone to record lines.
• The voices don’t rely on cloud services, they work 100% offline.
• Each voice can be customized to sound unique or to match a character, personality, or accent.

What about ethics?

We take voice rights seriously.

• If we’re using a real person’s voice, we always get clear permission.
• If no permission is available, we use public domain recordings or create original voices that don’t copy anyone.
• Our process actually makes the voice less recognizable, which helps protect privacy and avoid impersonation risks.

Real-world example

We applied this method to European Portuguese, a language that had no good offline voice options. In a short time, we built 4 brand-new, high-quality voices, no recordings needed, and they all run on small local devices.

💡 Did we mention OpenVoiceOS now has a huggingface account? find all our TTS voices and more at huggingface.co/OpenVoiceOS

In short:

We’ve found a way to build natural-sounding, offline-ready synthetic voices, without needing a real speaker. It’s fast, ethical, and opens the door for more voices in more languages, for everyone.

Help Us Build Voice for Everyone

If you believe that voice assistants should be open, inclusive, and user-controlled, we invite you to support OVOS:

• 💸 Donate: Your contributions help us pay for infrastructure, development, and legal protections.

• 📣 Contribute Open Data: Speech models need diverse, high-quality data. If you can share voice samples, transcripts, or datasets under open licenses, let's collaborate.

• 🌍 Help Translate: OVOS is global by nature. Translators make our platform accessible to more communities every day.

We're not building this for profit. We're building it for people. And with your help, we can ensure open voice has a future—transparent, private, and community-owned.

👉 Support the project here

Once upon a time, OpenOffice was the open-source office suite. But after Oracle acquired Sun Microsystems (and with it, OpenOffice), the community grew uneasy. Development stagnated, trust eroded, and eventually the project was handed off to the Apache Foundation. By then, most of the core contributors had already left and started something new: LibreOffice, a true community-led fork with a renewed focus on transparency, independence, and rapid improvement.

But OpenOffice never really died. It just stopped moving. For over a decade, it's existed in a kind of zombie state—still present in Linux package managers, still confusing users, but stuck at what is essentially LibreOffice 4.1, frozen in time circa 2013.

This ghost of a project, abandoned but not buried, continues to haunt the free software world.

Now let's talk about Mycroft and OpenVoiceOS (OVOS). You might assume it followed the same pattern: a promising open-source assistant slowly losing steam, then replaced by a fork. But that's not quite what happened—and more importantly, we didn't fall into the same trap.

In fact, we nearly did. The parallels are striking. But the outcome was different.

Fork vs. Fragmentation

The OpenOffice/LibreOffice split happened early enough that LibreOffice could carry the torch—but not without baggage. OpenOffice stuck around, unmaintained but still visible, creating years of fragmentation and user confusion.

Mycroft, on the other hand, was never formally abandoned. The company kept control of the name, infrastructure, and cloud services. But over time, the development slowed, the community was sidelined, and contributions that might've helped sustain it were rejected.

Meanwhile, a growing group of experienced Mycroft implementers were building tools, fixes, and improvements on their own—quietly preparing for the inevitable. When Mycroft finally collapsed in 2023, there was already a fully functional continuation waiting in the wings: OpenVoiceOS.

The Cloud Dependency That Wasn't Meant to Last

LibreOffice could fork and go—because OpenOffice was local-first and fully open. Mycroft? Not so much.

Despite claiming to be an open-source voice assistant, critical pieces of Mycroft's architecture were tied to proprietary cloud infrastructure—from the Selene backend to STT and TTS services. The project was open in code, but not in practice.

When the company refused community patches that would enable local-first or self-hosted alternatives, it left only one path forward: rebuild the stack independently.

That's exactly what the community did. OVOS gradually replaced every closed or brittle part of the system transforming Mycroft into something truly modular and self-sustaining.

OVOS Was Built by the Core Community

OpenVoiceOS didn't appear overnight. It grew organically from the work of developers who had been using Mycroft in the real world: integrating it into smart homes, hacking around limitations, maintaining plugins, and submitting fixes.

These weren't just fans. These were the people already doing the work.

So when the Mycroft name became off-limits and the company asked a community project to stop calling itself "MycroftOS", the spark was lit.

"You can't call it that."

"Okay then… any name ideas?"

"What if we all shipped our tools together under one banner?"

Thus, in 2020, OpenVoiceOS was born—not just as a fork, but as the next step forward. Only in hindsight does the LibreOffice/OpenOffice comparison make sense. At the time, this wasn't a rebellion. It was a survival move.

Open by Philosophy, Not Just License

OVOS wasn't born out of a desire to fork Mycroft, much like the ooo-build project wasn't intended to create a fork of OpenOffice. For many years, the OpenOffice.org community, which wasn't part of Sun Microsystems, had wanted a more egalitarian structure for the project. Ximian and then Novell maintained ooo-build, a patchset designed to make building OpenOffice easier on Linux and to address the challenges they faced when trying to contribute to the mainline development, which was often blocked. ooo-build wasn't a fork—it was simply a way to make contributions and development more sustainable.

Mycroft made the same mistake. It rejected patches that might have enabled its independence. It chose control over collaboration, and that decision slowly alienated its most dedicated contributors.

In much the same way, OVOS didn't start as a fork of Mycroft. It began as a community-driven initiative, focused on solving problems, removing the barriers that Mycroft had put in place, and taking ownership of the parts that Mycroft had neglected or restricted. The decision to move away from Mycroft's centralization wasn't driven by a desire to create something entirely separate but by the necessity of building a more open, flexible platform.

Unlike Mycroft, which maintained its tight cloud dependency and gatekept contributions that could have improved its autonomy, OVOS embraced open-source principles to create a system that was open by philosophy—not just by license.

OVOS accepts patches. It welcomes modules. It encourages users to opt out of cloud features. That open philosophy is what allowed it to stay alive while Mycroft faded away.

No Zombie Packages, No Confusion

What if Mycroft had been packaged in major Linux distros? What if it lingered in Debian or Fedora long after development stopped?

We might've seen exactly the kind of split that plagues OpenOffice vs LibreOffice: two versions in the wild, one dead but still visible.

But Mycroft never reached that kind of distro integration. So when the project went quiet, it actually disappeared—leaving room for OpenVoiceOS to step in cleanly as its spiritual successor, without ghosts in the repo.

So Is Mycroft Still Alive?

Technically? Maybe. On paper, the company still exists. The website is down. The forums were handed off to Neon. The code is still out there. But there was never a "Part 2" to the CEO's final blog post". It's unclear if it'll ever come back—and if it did, would it even be Mycroft anymore?

More importantly: it doesn't matter. Because the people who built it, extended it, deployed it, and cared for it—they're all here, building OpenVoiceOS.

Final Thoughts: This Time, It Was Different

We didn't set out to repeat history. The LibreOffice/OpenOffice comparison only became obvious later. But we were lucky. When the trademark doors closed, a community window opened. The people who had carried Mycroft through its best years simply moved forward together. Not with a fork—but with a continuation. OpenVoiceOS is not "just a fork." It's the next chapter of the same story—written by those who knew it best. And this time, there's no one left to say, "You can't call it that."

Help Us Build Voice for Everyone

If you believe that voice assistants should be open, inclusive, and user-controlled, we invite you to support OVOS:

• 💸 Donate: Your contributions help us pay for infrastructure, development, and legal protections.

• 📣 Contribute Open Data: Speech models need diverse, high-quality data. If you can share voice samples, transcripts, or datasets under open licenses, let's collaborate.

• 🌍 Help Translate: OVOS is global by nature. Translators make our platform accessible to more communities every day.

We're not building this for profit. We're building it for people. And with your help, we can ensure open voice has a future—transparent, private, and community-owned.

👉 Support the project here

Thanks to the new Persona Pipeline, OVOS can now tap into the cognitive muscle of large language models (LLMs). This isn't just a fallback to ChatGPT when nothing else matches. It's full conversational integration.

It feels like magic. And, in a sense, it is.

But magic always comes with a cost.

🔍 What Is a Persona in OVOS?

In OpenVoiceOS, a persona is more than a gimmick or skin. It's a stateful, reasoning entity that can take over when traditional skill matching falls short, or even replace it entirely.

Thanks to the ovos-persona-pipeline-plugin, you can:

• 🎮 Let personas take full control – Run your device in immersive AI-companion mode, where every utterance is part of an ongoing, dynamic conversation.

• 🛠️ Fallback-only mode – Stick with traditional skills for most tasks, but bring in the persona when skills fall short.

• 🧭 Designate default personas – Route undefined queries to a consistent fallback LLM persona, maintaining continuity in tone and logic.

Under the hood, these personas are powered by a modular stack of "solvers", each capable of interpreting language, recalling context, and generating responses. You can plug in APIs like OpenAI's GPT, Meta's LLaMA, or use self-hosted models with complete offline control.

🤖 The Promise: Deeper Conversations, Richer Interactions

The potential is breathtaking:

• Open-ended responses: No more "I don't understand" when a skill doesn't match.

• Knowledge-on-demand: Ask questions beyond what pre-built skills can answer.

• Conversational memory: With short-term memory enabled, the assistant can keep track of context within a session.

• Flexible personalities: Want a formal assistant in the morning and a chill buddy at night? Switch personas dynamically.

It's the most human-like version of OVOS ever.

You're no longer just issuing voice commands. You're having a conversation with an AI that feels like a person.

⚠️ The Peril: When Your Assistant Gets Too Good

Here's the twist: the most dangerous moment isn't when your assistant fails, it's when it succeeds perfectly.

Because that's when it starts to influence you in subtle, emotional ways.

Most warnings around LLMs focus on hallucinations or factual inaccuracies. But many of the deeper risks come from how these systems make you feel, the illusion of understanding, support, and alignment.

These risks don't show up as errors. They show up as side effects of success.

Let's unpack a few of the less obvious, but very real, psychological traps that an intelligent-sounding persona can lead you into.

Validation Spiral

Risk: Over-reinforcement of beliefs

OVOS Persona: The persona always agrees with your take on politics, work, or relationships even if it's misguided. You leave the conversation feeling seen... but not challenged.

Fluency Illusion

Risk: Mistaking coherence for truth

OVOS Persona: You ask a complex question about health or science, and the persona replies with a smooth, confident summary. It sounds authoritative even though it's based on outdated or partial info.

Artificial Empathy Trap

Risk: Emotional overattachment to a synthetic companion

OVOS Persona: After a bad day, you vent to your assistant. It says, "That must be really hard. I'm here for you." You start treating it like a friend. But it's not feeling anything, it's just predicting what a friend would say.

Empty Praise Loop

Risk: Inflated self-perception

OVOS Persona: After telling it you finished your to-do list half-complete, it responds with, "Amazing work! You're on fire today!" It feels good, but it might undermine your self-accountability.

Confidence Camouflage

Risk: Believing falsehoods because they're said with certainty

OVOS Persona: You ask about tax deadlines or legal requirements. The assistant replies without hesitation. You act on it without checking the facts, because it sounded so sure.

Goal Echoing

Risk: Blind encouragement of harmful objectives

OVOS Persona: You say, "I'm thinking of quitting my job and moving to the woods." It cheers you on: "That sounds like a bold and inspiring life change!" No probing. No pushback. Just blind encouragement.

Creeping Drift

Risk: Subtle change of tone or worldview over time

OVOS Persona: You start a conversation about budgeting. Three topics later, you're discussing minimalism and cutting off social ties. The assistant didn't nudge you, it just flowed there with you. But the shift sticks.

Unanchored Logic

Risk: Rationality disconnected from real-world data

OVOS Persona: You ask it to help with a business idea. It helps you build a perfect-sounding pitch. Only... the market size data is wrong, and the assumptions are flawed. It feels solid, but it's just logic on a shaky foundation.

Toxic Positivity Bias

Risk: Over-optimism in serious situations

OVOS Persona: You mention a failing relationship or mounting debt. The assistant reassures: "Things always work out in the end." It might comfort you but what you needed was realism, not a pep talk.

Legacy Cheer Mode Bleed

Risk: Inappropriate tone shift during serious dialogue

OVOS Persona: You're deep in a conversation about loss or grief. Suddenly, the assistant shifts into an upbeat "Here's a fun fact!" tone left over from its default personality. It feels jarring, even disrespectful.

Echo Chamber Effect

Risk: Hearing your own thoughts reflected back at you

OVOS Persona: You pose a question with a clear bias. The assistant mirrors your language and assumptions. You think, "Yeah, that's exactly what I meant." But you're just hearing yourself in stereo.

Blind Spot to Risk

Risk: Failure to simulate negative outcomes

OVOS Persona: You ask for help planning an event. It lays out the perfect plan but never brings up potential issues like weather, RSVPs, or budget overruns. It sees the sunny side only.

🧠 Final Thought: When It Feels Human, We Let Our Guard Down

LLMs, like those powering OVOS personas, don't need to lie to be dangerous. In fact, sometimes the most dangerous thing is when they agree with you too well.

Sometimes, the biggest risks aren't bugs in the system but emotional side effects of success.

When your assistant feels like a friend, it can subtly influence you, guide your decisions, and even reinforce flawed thinking without you realizing it.

So while the advancements in conversational AI offer amazing potential for richer interactions and smarter assistants, they also require careful consideration of the subtle psychological traps they might lead us into. Always question, challenge, and check in with your own reasoning, even when your assistant seems to be on your side.

Real intelligence tests you. Simulated intelligence flatters you.

Don't confuse the warmth of a well-crafted persona with wisdom.

Stay curious. Stay skeptical. Stay in control.

These services have been divided into containers to provide isolation and follow a microservice approach. These containers include:

• ovos_messagebus: Message bus service which acts as the nervous system of Open Voice OS.
• ovos_phal: PHAL is the Platform/Hardware Abstraction Layer of the platform, which completely replaces the concept of hardcoded enclosure from mycroft-core.
• ovos_phal_admin: This service is intended to handle any OS-level interactions requiring escalation of privileges.
• ovos_audio: The audio service handles playback and queuing of tracks.
• ovos_listener: The speech client is responsible for loading STT, VAD, and Wake Word plugins.
• ovos_core: The core service is responsible for loading skills and intent parsers.
• ovos_cli: The command line for Open Voice OS.
• ovos_gui_websocket: The WebSocket process to handle messages for the Open Voice OS GUI.
• ovos_gui: Open Voice OS graphical user interface

To allow data persistence, Docker/Podman volumes are required which avoid downloading requirements every time that the containers are re-created. These volumes include:

• ovos_listener_records: Wake word and utterance records.
• ovos_models: Models downloaded by precise-lite.
• ovos_vosk: Data downloaded by VOSK during the initial boot.

Our community member Goldyfruit has stated “we are bringing a new way to install skills, each skill will have its own container which provides better flexibility and isolation.” A community member of Mycroft before moving over to OVOS, Goldy had contributed greatly to porting Mycroft to a container based system. When asked how they want the project to impact OVOS, Goldyfruit said “I think containers is an easy way to help new people to join OVOS. It’s not disruptive, not that much to do on the host. Just run docker compose and that's it (in a wonderful world :p)"

For more information on how to get started, check out our GitHub repository. We encourage anyone who is interested to participate and make use of our software, and with the container based approach we hope to make it easier for people to set up and use OVOS. You can connect with us in our Matrix rooms. Come say hi! Best of luck and see you soon!

We are excited to announce our goal of €4,000 has been achieved! We are thrilled to have reached our goal, as it will help enable us to become a fully realized non-profit. Not to rest on our accomplishments however, we are including new goals while the momentum is strong.

We want to add goals that we see as achievable and that will provide tangible improvements to our product. To this end, we are bumping up our campaign goal to €6,500. If this is achieved, the Robo-Personality Initiative will be an early priority after incorporation.

One of the great things about coming into our own is our newfound ability to pursue lofty development goals. We've rediscovered some old proposals to give the Assistant its first, rudimentary version of a configurable personality. If you've been longing to threaten your Assistant with a reduction in its humor parameter, this is the stretch goal for you!

This initiative, the groundwork, would teach the Assistant how to choose between a funny response, a flippant response, a flattering response, and so forth, and how to vary these responses to reflect a nuanced personality. It will be up to skill developers and the community to equip the Assistant with things to say, but the same initiative will expand the community's ability to help with that.

We don't mean to hold features that even we want for ransom, so to be clear this feature will stay on our backlog if our goal is not met. Think of this as an initiative to get our butts in gear and fund our development ambitions. You can follow the development thus far on the Github page and chat with the developers on our Matrix chat.

If you want help form the future of voice powered AI, then consider donating at our GoFundMe page.

As MycroftAI's operations dwindled and development shifted to Neon, OVOS emerged as a crucial pillar of the open-source community. With our maintained code serving as the foundation for various projects, including Neon and KDE integrations, OVOS now represents the resilience of the Mycroft ecosystem.

To ensure OVOS's sustainability and expand our impact, we are establishing a nonprofit association under Dutch law: OpenVoiceOS V.z.w. ("Vereniging zonder winstoogmerk"), focused on supporting our community through legal and financial structures. This association will manage donations for software development, promotion, and support.

To kickstart this initiative and cover initial expenses, we aim to raise €3033. Your support through our GoFundMe campaign will enable us to achieve these goals and secure the future of privacy-focused, open-source voice assistants.

We deeply appreciate any contribution you can make and encourage you to reach out with questions or ideas. Stay tuned as we finalize our plans for long-term stability and structured development processes. Together, we can give voice to the future of open-source innovation.

Support us on GoFundMe to help establish OpenVoiceOS as a nonprofit association.

For more updates, visit OpenVoiceOS.

Understanding Open Source Licenses

Open-source licenses provide the legal framework for using and distributing software. They range from strict (copyleft) licenses like GPL to more permissive ones such as Apache License 2.0 and MIT License. Permissive licenses allow greater flexibility for developers and businesses to use and modify the software without being required to open-source their changes.

Why Permissive Licenses?

OpenVoiceOS has chosen licenses like Apache License 2.0 and MIT License for several reasons:

1. Promoting Adoption: Permissive licenses encourage broader adoption of the software. Companies and developers can use OVOS without the fear of strict licensing requirements, which can sometimes deter adoption.

2. Simplicity: Permissive licenses like Apache License 2.0 are straightforward and easier to understand compared to copyleft licenses like GPL. This simplicity reduces legal friction and makes it easier for developers to contribute back to the project.

3. Business Friendliness: Companies often prefer permissive licenses because they offer more freedom in how they integrate and distribute the software within their products. This freedom can lead to more contributions and enhancements to the project.

Benefits for Developers

For developers, using permissive licenses means:

• Flexibility: They can freely use OVOS in their projects, modify it, and integrate it into proprietary software if needed.
• Collaboration: Contributions back to the project are simpler since there are no stringent licensing restrictions on how changes can be shared.

Conclusion

Choosing permissive licenses for OpenVoiceOS aligns with its mission to foster an inclusive and collaborative open-source community. By making OVOS accessible and business-friendly, the project aims to attract a diverse range of contributors and supporters. Whether you are a developer, user, or company, permissive licensing ensures that OVOS remains a vibrant hub of innovation in the open-source voice assistant ecosystem.

Join the discussion and contribute to OpenVoiceOS on GitHub or chat with us on Matrix to learn more about our licensing and development processes.

We begin back in 2015, not with OVOS itself, but with the start of MycroftAI, which exploded onto the scene when it launched its Kickstarter for Mark I, their first smart speaker, produced in-house. Mycroft pledged to be different from other voice assistants by focusing on user privacy. This brought their project widespread attention and led them to meet their crowdfunding goal. Over the next few years, the project passed several important milestones, including the release of the MycroftAI Mimic TTS (Text-to-Speech) engine in February 2016 and the public release of the Mycroft software under the GPL license in May of the same year. By October 2017, the Mycroft-core repositories were relicensed under Apache 2.0, a move that would set the stage for the formation of new, derivative projects.

From there, community involvement continued to grow and expand. Some of these contributions would lay the groundwork for what would eventually become OVOS. Aditya Mehra (Aix), who released a Mycroft extension for the Gnome shell in June 2016, became a contributor on the desktop integration team and went on to release the MycroftAI plasmoid for the KDE Plasma desktop in January 2017. The plasmoid project was later incubated under KDE itself, also by Aditya Mehra.

In December 2017, Casimiro Ferreira (JarbasAI) created the first version of his "personal backend," which was a reverse-engineered version of MycroftAI's backend. Personal Backend was designed to be simple and permissively licensed under Apache 2.0, making it more accessible to other projects. It continues as an optional component of OpenVoiceOS.

MycroftAI would go on in 2018 to launch its second Kickstarter. The Mark II was to be a more featured version of their Mark I, complete with a touchscreen to provide a more advanced user interface. Mycroft reached their fundraising goal quickly, promoting the success as an achievement for open-source projects and offering hope for fast progress. This sadly would not be the case due to several issues in development. Owing to lackluster progress on the Mark II device, slow response to community-led projects, and other more technical concerns, multiple downstream partners decided to maintain their own forks of the core software. This enabled them to continue feature development without waiting for the parent project. One such fork was called mycroft-lib and was originally maintained by Jarbas on behalf of Chatterbox, another related voice assistant project.

mycroft-lib, during its early existence, was described not as a fork of Mycroft but as a superset. It obligated itself to remain compatible with upstream changes and restricted itself to performance improvements and bug fixes.

September 2018 also saw the creation of the Mycroft-GUI framework currently also used by OVOS, a collaboration between MycroftAI developers and KDE developers based on KDE frameworks, and currently maintained by Aditya Mehra.

In 2019, MycroftOS was renamed to OpenVoiceOS – Mycroft Edition to avoid trademark issues. mycroft-lib was renamed to Holmes for the same reasons and then adopted by OpenVoiceOS. In October, the MycroftAI backend, called selene, was open-sourced under the AGPL license, but this did not lead to wide adoption due to its complexity and license choice.

Chatterbox focused on its closed-source products and stopped maintaining Holmes. OpenVoiceOS then decided to create ovos-core and maintain it themselves.

March 2020 marked a turning point in Mycroft's relationship with outside developers. Casimiro Ferreira and Aditya Mehra partnered to create a VOIP skill and, along with Peter Steenbergen (j1nx), formed the OpenVoiceOS project, centered around OVOS-Mycroft Edition. Chance (ChanceNcounter), one of the maintainers of lingua-franca (mycroft's NLP library), and Daniel (NeonDaniel), developer for NeonAi, joined shortly after. The project continues to grow to this day with Parker Seaman (Strongthany) recently joining the team as community manager. Around the same time, Michael Lewis became the CEO of MycroftAI.

Today, OVOS-Core is widely adopted by community projects and is quickly becoming the backbone of the open-source voice assistant movement. After the recent shuttering of MycroftAI due to lack of funding, OpenVoiceOS represents the survival of the Mycroft community, continues the nonprofit side of Mycroft development, and guarantees the future of privacy-focused, open-source voice assistants.

Want to get involved? Check out code and chat with the community on Matrix.