mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-07 03:18:23 -05:00
[GH-ISSUE #11594] issue: TTS Configuration Not Routing to Custom OpenAI-Compatible API (Routes to Kokoro Instead) #31817
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#31817
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @sunruichao on GitHub (Mar 12, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/11594
Check Existing Issues
Installation Method
Git Clone
Open WebUI Version
v0.5.20
Ollama Version (if applicable)
No response
Operating System
Ubuntu 24.10
Browser (if applicable)
No response
Confirmation
README.md.Expected Behavior
Please investigate why the TTS configuration is not routing to the custom OpenAI-compatible API (CosyVoice) and instead falls back to Kokoro, especially given that Kokoro Fast API works. Suggestions on debugging, adjusting configurations, or patching the routing logic would be greatly appreciated. Additional guidance on enforcing the use of the specified API endpoint would also help.
Actual Behavior
When configuring Open WebUI to use a custom OpenAI-compatible TTS API (e.g., CosyVoice at http://:3005/v1), the TTS requests are not routed to the specified API. Instead, the system falls back to the default Kokoro engine, despite correct environment variable settings and interface configuration. Interestingly, configuring Kokoro Fast API within the same Open WebUI instance works successfully, indicating the issue is specific to routing custom OpenAI-compatible APIs.
Expected Behavior
The TTS request should be sent to http://192.168.18.98:3005/v1/audio/speech and generate audio using the custom CosyVoice API.
Actual Behavior
The TTS request routes to the default Kokoro engine, or no TTS request is triggered. Network requests show no activity to the custom API endpoint. However, configuring and testing with Kokoro Fast API works as expected.
Environment
Open WebUI Version: v0.5.20
OS: Linux (Ubuntu 22.04)
Docker Version: 20.10.7
Custom API: OpenAI-compatible TTS API (CosyVoice) running at http://192.168.18.98:3005/v1
Kokoro Fast API: Tested with default or local configuration (works successfully)
Steps to Reproduce
Attempts to Resolve:
Set LOG_LEVEL=DEBUG to capture more details, but it did not change the log level.
Set ENABLE_DEFAULT_TTS=False to disable the default engine, but it had no effect.
Disabled OLLAMA_BASE_URL= to avoid interference, but Ollama connection errors persisted.
Verified the custom API works with a Gradio test script, successfully generating audio via http://192.168.18.98:3005/v1/audio/speech with logs:
2025-03-12 23:43:32,165 INFO Received TTS request for /v1/audio/speech
...
INFO: 192.168.18.98:58406 - "POST /v1/audio/speech HTTP/1.1" 200 OK
Contrast with Kokoro Fast API:
Configuring Kokoro Fast API within the same Open WebUI instance and testing with the play button worked successfully, indicating the TTS functionality is operational but fails specifically with custom OpenAI-compatible APIs.
Possible Cause:
The issue may be related to how Open WebUI handles custom OpenAI-compatible API endpoints or voice mappings.
Logs & Screenshots
Please investigate why the TTS configuration is not routing to the custom OpenAI-compatible API (CosyVoice) and instead falls back to Kokoro, especially given that Kokoro Fast API works. Suggestions on debugging, adjusting configurations, or patching the routing logic would be greatly appreciated. Additional guidance on enforcing the use of the specified API endpoint would also help.
Additional Information
No response