Can I use this for my phone system's greetings?

Not directly. The documentation describes voice cloning, dubbing and a local speech service, not an IVR integration. The realistic path is to generate the audio locally, export the files, and upload them to whatever phone provider you already use. Treat it as an audio production tool, not a telephony product.

What hardware do I need?

The project auto-detects CUDA, MPS, ROCm or CPU, so it will start on most machines. What the docs do not state is what runs comfortably. Test with step three of the plan, a single transcription on a file you already have, before committing more time. If that step crawls, the rest will too.

Is it really free, with nothing going to a server?

The project states that it runs entirely on your machine, that no API keys or accounts are needed, that remote services are optional, and that usage analytics require consent. Verify that on your own install by watching outbound traffic during a job rather than taking any write-up, including this one, at its word.

Voice cloning on your own hardware: a three-hour plan for VoiceStudio

The interesting thing about VoiceStudio is what the documentation actually commits to, which is narrower and more useful than the headline.

What the docs actually say

The repository describes itself as an open-source, fully local alternative to hosted voice services, covering voice cloning, voice design, video dubbing, dictation, transcription and audiobook creation, with support claimed for 646 languages.

The project's CLAUDE.md says it runs entirely on your machine and auto-detects CUDA, MPS, ROCm or CPU, with no API keys, no accounts and no cloud dependencies. Local workflows run on your hardware, remote services are optional, and usage analytics require consent.

The speech platform doc is the part most coverage skips: it is both a desktop dictation app and a headless local speech service, with a bundled Rust control sidecar and a Python backend that keeps the speech models warm. Headless plus a local API is what makes it scriptable from your own tools.

What the docs do not describe: an IVR product, a phone-system integration, or a quality bar for training-video dubbing. Those are inferences, not documented features.

What this means for an owner

You can take recurring, low-risk voice work (greetings, internal walkthroughs, first-pass dubs) off metered billing and onto a machine you already own, at the cost of your own setup time and your own quality control.

That is it. It is not a phone system, and I have not tested the output quality.

The plan, about three hours

Hands-on time. Model downloads run in the background and are not counted.

Read the release notes and check your hardware. About 20 minutes. The release notes list a one-command install for macOS, Linux/WSL and Windows: copy it from the releases page, not from a blog post.
Install and let it detect your accelerator. About 25 minutes.
Warm the models and run one transcription of a file you already have. About 30 minutes. If this is slow, everything downstream is slow.
Record a clean sample and create one cloned voice. About 40 minutes.
Dub one short clip end to end. About 35 minutes.
Export, file the artefacts, write down what broke. About 30 minutes.

That totals about three hours. If step three crawls on your machine, stop there: the answer is no for now, and you have spent about 75 minutes finding out.

The pre-flight checklist

Run this before you install anything. Three noes and this is not your week.

There is a machine with a discrete GPU or Apple silicon that is idle for long stretches.
Someone owns the output. A cloned voice with no reviewer becomes a quality incident.
You have written consent from whoever's voice is being cloned, in writing, before recording.
The use case tolerates a retake. Greetings and internal training do. Legal notices do not.
You can name the file that leaves the machine and where it goes next.
You have a clean sample: one room, one mic, no background noise.

The arithmetic

Do it on your own inputs, not mine. Monthly voice minutes times your current per-minute rate gives your annual spend. Against that put your setup hours times what your time is worth, plus your recurring quality-check time per asset. If your monthly minutes are small, hosted billing wins and this is a hobby project. If you regenerate the same greetings and training clips every month, the fixed cost starts to look better.

Limitations

IVR is not documented. Anything phone-related means exporting audio and uploading it to your existing phone provider.
646 languages is a repository claim about coverage, not evidence that every language is production-stable.
Hardware requirements for comfortable local inference are not stated anywhere I could verify. My guess is that a CPU-only office laptop will be painful, but I have not tested it.
Cloned-voice quality against hosted services is unmeasured here. Judge it with your own ears on your own script.
Voice cloning carries consent and impersonation risk that no tool solves for you.

My take

The local API and headless mode are the real story, not the cloning. A speech service you can call from your own scripts, with no per-minute meter and no data leaving the building, is a useful building block for internal tooling. Spend the three hours, keep the notes, and only then decide whether anything customer-facing goes near it. More build write-ups are at tarunsai.com/blog.