OmniVoice HTTP TTS Server

[breezerider]

What

Adds an HTTP REST API (omnivoice-tts-server) for text-to-speech generation, exposing an OpenAI-compatible endpoint at /v1/audio/speech. The server runs as a standalone binary built from the tools/omnivoice-tts-server.cpp source.

New files:

• tools/omnivoice-tts-server.cpp: HTTP server implementation using cpp-httplib
• examples/client.sh: CLI client to call the API with jq-based JSON construction
• examples/server.sh: Helper script to launch the server with model paths

Modified:

• CMakeLists.txt: Added OV_WEBSERVER option and new build target

Why

Provides a networked interface to OmniVoice's TTS pipeline, enabling:

• Remote TTS generation from scripts, services, or other applications
• Compatibility with existing OpenAI TTS clients (minimal client changes required)
• Integration into distributed systems or containerized deployments

The server supports:

• WAV output formats (16/24/32-bit)
• Language/style instructions via --lang and --instruct CLI flags
• Long-form synthesis with chunking (configurable via --chunk-duration)
• OpenAPI documentation at /v1/api-docs

How to Review

1. CMakeLists.txt: See the conditional build block for omnivoice-tts-server. Note the dependency on httplib and nlohmann_json.

2. tools/omnivoice-tts-server.cpp: Start with main() to understand CLI argument parsing, then:

   • generate_audio_task(): Worker thread that calls ov_synthesize() and encodes WAV
   • HTTP endpoint at /v1/audio/speech: Request validation, JSON parsing, async worker dispatch
   • /v1/api-docs: OpenAPI spec generation (static, no dynamic routing)

3. examples/client.sh: Shows how to call the API from bash using jq to construct JSON payloads.
   Optinally, two environment vrables can be used to configure the client:

• OV_SERVER sets the webserver address (defaults to http://127.0.0.1:1234)
• OV_OUTPUT sets the output path (defaults to output.wav)
• OV_TIMEOUT sets the client request timeout in seconds (defaults to 300 seconds)

4. examples/server.sh: Demonstrates server launch with model paths and default configuration.
   Command line arguments are forwarded to the omnivoice-tts-server executable.

What's intentionally left out:

• Voice cloning support (TODO comments in generate_audio_task())
• Speed control (dummy field accepted but ignored)
• Streaming responses (full WAV returned as binary blob)

Testing

• Build with OV_WEBSERVER=ON and verify omnivoice-tts-server binary is created
• Run examples/server.sh and confirm server starts on port 1234
• Call /v1/api-docs and verify OpenAPI spec is returned as JSON
• Run examples/client.sh with a test prompt and verify WAV output
• Test error cases: missing input field in JSON payload, invalid JSON, unsupported format

Deployment Notes

• Build requirement: Enable with OV_WEBSERVER=ON in CMake
• Dependencies: httplib (C++17 header-only), nlohmann_json (header-only)
• No environment variables required: server configuration provied on the command line (binds to 127.0.0.1:1234 by default)
• Safe for containerization: all dependencies are header-only or static
• Model paths: Server expects at least the --model and --codec CLI args (no env var fallback)

[ServeurpersoCom]

The idea of ​​compatibility with OpenAI is good, and I want to keep it. However, I'm also working on qwentts.cpp (https://github.com/ServeurpersoCom/qwentts.cpp) and I haven't yet decided whether to merge the two projects to avoid duplication.

[SarcasticBaka29]

The idea of ​​compatibility with OpenAI is good, and I want to keep it. However, I'm also working on qwentts.cpp (https://github.com/ServeurpersoCom/qwentts.cpp) and I haven't yet decided whether to merge the two projects to avoid duplication.

Not sure if you have decided which direction you want to take this project in regard to a potential merge with qwentts. But as it is right now it works pretty darn well, and I'd personally love an OpenAI-compatible, ideally cloning and streaming capable HTTP server in order to integrate this project with various frontends.

[AvinashSKaranth]

Tested the workflow and does not break anything in the core application. This should be merged so that it can generate streaming test very quickly.