TTS Audio Suite: a multi-engine TTS and voice conversion node pack for ComfyUI

What TTS Audio Suite adds to a ComfyUI graph

ComfyUI is a node graph, and speech is normally bolted onto it one model at a time. Each TTS project ships its own loader, its own sampling node, its own quirks, and its own Python dependency set. Switching from one voice model to another usually means switching repositories, not switching a dropdown.

TTS Audio Suite takes the opposite position. It is one custom node pack that wraps many engines behind a shared node surface: Chatterbox (classic and a 23-language official checkpoint), F5-TTS, Higgs Audio 2 and v3, Step Audio EditX, MOSS-TTS, Echo-TTS, IndexTTS 2 and 2.5, CosyVoice3, Qwen3-TTS, VibeVoice, DramaBox, OmniVoice, Fish Audio S2 Pro, Dots TTS, Granite ASR, MOSS-SoundEffect v2 and RVC. The README describes the intent as a unified architecture with runtime isolation for fragile legacy stacks, sitting on a Transformers 5 main environment. The target user is someone building a dubbing or narration pipeline inside ComfyUI who wants to audition engines without rebuilding the graph.

The second audience is subtitle work. The project grew out of a Chatterbox SRT voice repository, and it can transcribe to SRT, rebuild subtitles from an edited transcript, or estimate fresh SRT timing from plain text. If your job is turning a script and a voice reference into timed audio, that lineage matters more than the engine count.

How the engine layer and the text layer fit together

The repository separates concerns at the directory level. engines/ holds the per-model integrations, nodes/ holds the ComfyUI-facing nodes, utils/ holds shared code, and install.py handles dependency resolution. A single YAML file, docs/Dev reports/tts_audio_suite_engines.yaml, is the source of truth for the comparison tables in the README, which are generated from it rather than hand-maintained.

The text layer is where the project has its own ideas. The README describes project control tags that survive subtitle processing so downstream TTS can still act on them. The evolution timeline names several: [pause:1s] for pauses, [German:Bob] for language switching, [Alice] for character switching, and [seed:24] for per-segment parameter switching. Inline editor tags such as <laughter:2> were introduced with Step Audio EditX. The practical effect is that a single transcript can carry speaker, language and timing instructions, and the SRT rebuild path preserves them instead of flattening them into plain sentences.

Runtime isolation is the other architectural decision. The main environment runs Transformers 5 for the newer engines, while older Transformers 4 engines get their own isolated runtimes. That is a deliberate trade: it avoids forcing every engine onto one version of a fast-moving library, at the cost of more disk and more install complexity. The dependency list reflects the same caution, pinning numpy below 2.3.0 and capping transformers at <6.0.0.

Installing TTS Audio Suite and running a first SRT job

The requirements file states the installation method explicitly: this custom node uses install.py for dependency management, and ComfyUI Manager runs it automatically. So the normal path is to install through the Manager rather than pip-installing the repository yourself. The same file lists what install.py handles: Python 3.13 compatibility (a MediaPipe to OpenSeeFace fallback), NumPy constraints, selective --no-deps installation, the bundled ChatterBox, F5-TTS and Higgs Audio engines, and optional RVC and mouth-movement features.

The README gives no clone command of its own, so the manual route is the one every ComfyUI custom node uses: place the repository under the custom_nodes directory of your ComfyUI install. The project's own repository URL is the source to copy from:

https://github.com/diodiogod/TTS-Audio-Suite

After installation, restart ComfyUI and load a workflow from example_workflows/. The repository ships example graphs, and the ComfyUI Registry icon points at example_workflows/Chatterbox SRT.jpg, which is the SRT-oriented example. Open that graph and check that the TTS Audio Suite nodes appear in the node menu before wiring anything yourself.

Model weights are not in the repository. The README links a model download sources document and a model folder layouts document, and the comparison table gives approximate sizes per engine: around 1.2GB per language for F5-TTS, around 4.3GB for Chatterbox, 5.4GB or 18GB for VibeVoice, roughly 9GB for Higgs Audio 2, and 100-300MB for RVC. Budget disk accordingly before you start pulling checkpoints.

One system dependency is easy to miss. The phonemizer package, listed for IPA phonemization in multilingual TTS, requires espeak to be present on the system. Without it, multilingual phonemization paths will not work even though Python dependencies installed cleanly.

Where the breadth becomes a liability

The engine table is the selling point and the main risk. Nineteen engines at those sizes means the full set is tens of gigabytes of checkpoints, and the project's own install notes describe conflict handling for NumPy, MediaPipe and package dependencies. That is not incidental complexity; it is the cost of the design. A user who only wants one voice model is paying for a framework built to host many.

The licence is the sharper issue. pyproject.toml declares license = {file = "LICENSE"}, and the repository metadata reports the licence as NOASSERTION, meaning no standard SPDX identifier was detected. The README does not state which licence the project is released under. Before shipping anything built with it, read the LICENSE file in the repository root and check the terms of each upstream engine separately, because the suite bundles or downloads models from many different sources and their terms are not necessarily the same. Nothing here is legal advice; the point is that the licence question is genuinely open from the repository metadata alone.

The README also does not document rollback. There is a CHANGELOG.md, and the timeline records a breaking rename at v4.0, but the README gives no procedure for reverting to an earlier version or for recovering a working environment after a dependency conflict. If you run this in a shared or production ComfyUI instance, snapshot the environment yourself before upgrading.

TTS Audio Suite compared with a single-engine TTS node

The obvious alternative is a dedicated node pack for one engine, such as a ComfyUI F5-TTS integration or a Qwen3-TTS node. The difference is architectural, not cosmetic. A single-engine pack installs one model family, one dependency set, and one set of loader nodes. Its install surface is small, its failure modes are well understood, and upgrading it rarely disturbs anything else in the ComfyUI environment.

TTS Audio Suite trades that simplicity for a common node interface across engines. You can change the engine behind a graph without rewiring it, and you get the shared text layer with control tags, character aliases, SRT rebuild and timing estimation. Those features do not exist in a single-engine pack, because they are only worth building when more than one engine has to share a transcript.

A second comparison is against running each engine as its own separate ComfyUI installation. That is the cleanest isolation possible, and it is what the suite's own runtime isolation is approximating inside one install. The suite wins on convenience and on the unified text pipeline; separate installs win on predictability. If you never switch engines, the suite's main advantage does not apply to you.

Maintenance, upgrades and who should adopt it

The last push to the default branch was on 2026-09-05, and the most recent releases listed are v5.6.0 (DramaBox and ChatterBox V3) on 2026-07-25, v5.5.3 (Character Alias Manager) on 2026-07-25, and v5.5.0 (MOSS-TTS v1.5, Sound Effects, and Unified Voice Design) on 2026-07-17. The version in pyproject.toml is 5.8.10 while the README heading reads v5.8.10, so the package metadata and the documentation are in step. The project is not archived.

That release cadence has a cost for adopters. Engines are added and replaced on a monthly rhythm, and the v4.0 breaking rename shows the project is willing to restructure. Upgrading means re-reading the changelog, re-checking model folder layouts, and re-verifying that your control tags still parse. The install.py dependency handling is the part most likely to break on a Python or NumPy upgrade, since it exists precisely to paper over those conflicts.

Adopt it if you are doing subtitle-driven dubbing or narration in ComfyUI, you expect to compare voices across engines, and you can afford the disk and the upgrade attention. Do not adopt it if you need a single stable voice model in a locked environment, or if you cannot accept an unresolved licence identifier. Before committing, verify three things: what the LICENSE file actually grants, whether your target engine's weights are downloadable from the sources the project lists, and whether install.py completes cleanly on your Python version.

Editorial conclusion

Adopt TTS Audio Suite if you are building subtitled dubbing or narration in ComfyUI and want to move between engines without rebuilding the graph; skip it if you need one stable voice model in a locked environment. Before you commit, open the LICENSE file, since the repository metadata reports NOASSERTION and the README does not name a licence, and confirm that install.py finishes on your Python version.

Frequently asked questions

Official sources

1. diodiogod/TTS-Audio-Suite on GitHub
2. Issues
3. README
4. Releases