Tried VoiceStudio on a CPU-only WSL2 box (source + Docker) — first-run notes

[nineshoot]

I ran VoiceStudio (open-source ElevenLabs alternative) on a CPU-only WSL2 box — here's what happened

VoiceStudio bills itself as a fully-local ElevenLabs alternative: voice cloning, voice design, video dubbing, dictation, transcription and audiobook creation across 646 languages, no account or API key required for the local workflow. 16.7k stars, AGPL-3.0, Python + FastAPI backend with a Tauri/React desktop shell.

I skipped the packaged desktop app and tried the backend two ways, on a CPU-only WSL2 machine (no CUDA): from source, and via the documented Docker quick-start.

Setup — from source

git clone https://github.com/debpalash/VoiceStudio.git
cd VoiceStudio
uv sync --no-dev
uv run python backend/main.py --diagnose

The self-check came back clean:

VoiceStudio self-check - v0.5.2 on Linux-6.18.33.2-microsoft-standard-WSL2-x86_64
[ OK ]   Python runtime: 3.11.15
[WARN]   Compute device: cpu (no GPU acceleration detected)
[ OK ]   Media engine (ffmpeg)
[WARN]   HuggingFace token: not set
[ OK ]   Disk space: 925.4 GB free
[ OK ]   TTS engines: active: omnivoice; available: omnivoice, kittentts, omnivoice-subprocess
8 ok, 2 warning(s), 0 failure(s) - looks healthy

Nice touch: it tells you up front it'll be slow on CPU instead of just quietly grinding.

Setup — Docker (once WSL integration was on)

docker run -d -p 127.0.0.1:3900:3900 \
  -v omnivoice-data:/app/omnivoice_data \
  --name voicestudio palashdeb/omnivoice-studio:stable

Pulled, booted, and passed its own healthcheck in under 20 seconds — no uv sync, no --diagnose, no local Python env to manage. This is clearly the path meant for "just try it."

Pitfalls (試坑)

• WSL2 without the Docker Desktop WSL integration enabled can't see docker at all — the documented one-liner silently isn't an option until you flip that toggle in Docker Desktop settings.
• Running --diagnose from source before the DB has ever been touched throws a noisy sqlite3.OperationalError: no such table: settings traceback to stderr — harmless (Alembic migrations run on the next real startup and create the table), but it looks scarier than it is on a first run. The Docker image sidesteps this entirely.
• First real request pulls down the OmniVoice model (~2.5 GB) and a separate AudioSeal watermarking model on top, so the first /v1/audio/speech call is a cold-start double-download, not just a model load — true for both the source and Docker paths.

Generating actual audio

Backend boots an OpenAI-compatible API on localhost:3900, no key needed:

curl http://localhost:3900/v1/audio/speech \
  -H "Content-Type: application/json" \
  -d '{"model": "tts-1", "input": "Made on my own hardware, no cloud, no API key.", "voice": "demo0001", "response_format": "wav"}' \
  --output speech.wav

First call (model download + load + AudioSeal watermark load + generation): 2m24s, entirely on CPU. Output: a clean 24kHz mono WAV, watermarked with AudioSeal by default — nice for a tool marketed at cloning voices.

Verdict

Genuinely local, genuinely OpenAI-API-compatible, and it degrades gracefully on hardware with no GPU — it just gets slow, not broken. The rough edges I hit were all first-run cold-start friction, not design flaws. If you have a CUDA or Apple Silicon box this would fly; on CPU it's fine for occasional use, not for anything real-time.

If you just want to poke at it: use Docker, it's the smoothest path by far. Reach for "run from source" only if you're planning to actually modify the code.