speech.cppは、音声合成・音声認識・音声区間検出をggml上で動かすC++のエンジンです。Irodori-TTSやQwen3-TTSで読み上げ、Qwen3-ASRやReazonSpeech NeMo v2で書き起こす処理を、同じコマンド体系とC APIから扱います。MacではMetal、WindowsとLinuxではVulkanを使い、CPUでも動きます。
開発記事で面白いのは、合成全体を速くするだけでなく、会話相手が待つ時間を分けて考えているところです。読み上げが実時間より速く終わっても、全文の完成まで再生を待つなら、返事の出だしは遅れます。
生成途中ではなく、デコード途中から返す
Irodori-TTSは、Diffusion Transformerが文全体の音声の潜在表現を作り、それをコーデックが波形へ戻す構造です。MF版はMeanFlowによる蒸留で生成を4ステップに減らしていますが、文の途中から潜在表現を順番に出すモデルではありません。
speech.cppが分割したのは、その後のデコードです。最初の0.48秒ぶんを波形に戻したら先に返し、再生中に残りを処理する。後続の区切りは、再生に追いつけるよう調整します。生成そのもののストリーミングと、波形を少しずつ返す仕組みは区別して読む必要があります。
参照音声も、毎回WAVから処理する代わりに、speech voiceで声のファイルへ変換して再利用できます。同じ声で何度も返事をする用途では、繰り返す処理を減らす工夫が効きます。
ただし、「最初の音声データが届くまで」と「声が聞こえ始めるまで」は別です。開発記事ではQwen3-TTSの先頭に無音が入る場合も検証しています。比較するときは、初回のモデル取得・読み込みや再生側の待ち時間も切り分けたいところです。
試す入口と、組み込む入口が揃っている
導入後にモデルを選んで試すなら、ブラウザの画面を開くコマンドがあります。
speech serve --openモデル名を指定して使う際は、必要なGGUFを初回にHugging Faceから取得します。配布版の実行にPythonやCUDAは不要です。ただし、Windows版にはVulkanローダー、Linux版にはCPU命令セットやglibcの条件があり、Intel Macはソースからのビルドになります。
アプリからは、HTTPサーバー、標準入出力でJSON Linesをやり取りするワーカー、共有ライブラリのC APIを選べます。HTTPはOpenAIの音声APIとRealtime文字起こしの一部に対応するもので、API全体を置き換えるわけではありません。また、標準の待ち受けは127.0.0.1で、認証もTLSもありません。別の端末から使うなら、それらを担うプロキシが必要です。
速さを試す前に、長い文の扱いを決める
v0.8.6のドキュメントには、Irodori-TTSのMF版で長い一文の途中が不明瞭になる場合があると記載されています。ttsとserveは文末で分割しますが、上限内に収まる長い一文まで、必ず読点で細かく切るわけではありません。必要なら入力側で分け、声を揃えるために同じ参照音声や声のファイルを使う、という対処が示されています。
ここでは公開資料を読んでおり、手元での速度や音質は未検証です。試すなら、短い返事と長い説明を両方用意して、最初の声、再生の途切れ、読みの崩れを聞き比べるのがよさそうです。会話用のエンジンとして選ぶなら、速度の数字ひとつより、実際に返す文章でどこまで待たずに聞けるかを確かめたいと思います。