elumenotion/guideants/audiocpp-host-tts

audio.cpp host-native engine (experimental)

The sandbox can reach an audiocpp_server the user runs natively on the host — same raw API as the container engines, but with whatever models and loaders their build has (e.g. a fork compiled with Kokoro enabled). Deliverables are WAV files in Output/.

Preflight

python3 Skills/audiocpp-host-tts/scripts/preflight.py --for host-tts

Resolution order: AUDIOCPP_ENGINE_URL env (set via the guide editor's Environment variables UI), else http://host.docker.internal:8080. The preflight also distinguishes a real audio engine from a llama-server that happens to answer /health on the same port.

Synthesizing

--model is required — there is no wrapper to auto-detect from:

python3 Skills/audiocpp-host-tts/scripts/engine_tool.py speech "Hello" \
  --engine-url http://host.docker.internal:8080 --model <engine-model-id> \
  -o hello.wav [--voice <id>] [--seed 42] [--language en] [--voice-ref ...]

List the models the host build serves: GET <base>/v1/models; voices: engine_tool.py voices --engine-url <base> --model <id>.

The consent rule applies to --voice-ref cloning here too: proceed for the user's own voice or a consenting speaker; decline third-party imitation.

Hard limit: TTS only

The host engine's /v1/audio/transcriptions takes a server-local path in its JSON body — files in this sandbox are not visible to the host process, so transcription against the host engine cannot work from here. Use the container ASR (the audiocpp-asr-extended skill) instead.

Troubleshooting

Reporting

End by telling the user what worked and what was blocked, quoting the preflight/engine evidence.