コアの変更への追従

[takana-v]

内容

• 動的ライブラリにモデルファイルを同梱する voicevox_core#99

initialize関数の引数が変更されているのでCoreWrapperの__init__に変更が必要です。

• Libcoreなどをリネームしないようにする voicevox_core#114

もしマージされた場合、コアのバージョン判別機構に変更が必要です。

Pros 良くなる点

Cons 悪くなる点

実現方法

VOICEVOXのバージョン

0.?.0

OSの種類/ディストリ/バージョン

• Windows
• macOS
• Linux

その他

完全に忘れていたのでメモ代わりのIssueです。
もし途中まで取り組んでいる方がいらっしゃったらself-assignをお願いします。

[Hiroshiba]

もしマージされた場合、コアのバージョン判別機構に変更が必要です。

ファイル名をコアの判定に使っていたことを完全に忘れていました･･･。

ファイル名統一の変更を加えると、過去バージョンのコアはもう使えなくなりそうな気がしています。
それはもう仕方ないということにして、これからどうすればバージョン判定でき続けるか考えたいかもしれません。
（過去のコアに関しては、なんとかして今のcoreコードでリビルドするという最終手段があります）

[PickledChair]

問題を整理したいと思ったので、現在の自分の認識と、考えうる対応策をまとめてみました。間違いや考え漏らし等ありましたらご指摘ください。

エンジンでのコア使用の流れ

現状は、以下のような流れで SynthesisEngine を使用することが可能になるという認識です：

---

1. make_synthesis_engines 関数が呼ばれる（引数としてコアのパスのリストが渡される）
2. 渡された複数のコアへのパスそれぞれに対して CoreWrapper を生成する
3. CoreWrapper の初期化処理内でコアが動的ロード・初期化される

• ここで libtorch 版か onnxruntime 版かが自動判別されている

4. 初期化済み CoreWrapper を使ってバージョン文字列を得る（metas 関数より）
5. CoreWrapper のデータを用いて SynthesisEngine を生成
6. {<バージョン文字列>: <SynthesisEngine インスタンス>} の形式で辞書に追加
7. make_synthesis_engines 関数の戻り値として上記辞書が返される

---

今回問題となるのは 3 の手順で、takana さんのご指摘の通り以下の２つの問題がありそうです：

• 新しいコアの実装では CoreWrapper の初期化で initialize 関数に対してコアのあるディレクトリ名を渡さないようにしなければならない
• 新しいコアではコア名が変更される見込み。実質 libtorch 版のときのコアの名前に戻ることになるため、libtorch or onnxruntime 版のコアかどうかをコア名から判断することが不可能になる

コアのタイプの自動判定のサポート範囲をどうするかによって、自動判定方法に関して以下のように対応が変わってきそうです：

libtorch 版コアの自動判定を引き続きサポートする場合

• コア名から libtorch or onnxruntime 版を判定することが不可能であるため、ヒントとなる別の情報を何らかの方法で追加する必要がある
  • 具体的な方法は思いつきませんでした……。少なくとも「コアのパスを渡すだけ」という現状の方法は維持できなさそうです コアの変更への追従 #385 (comment) の方法を用いると、従来通り「コアのパスを渡すだけ」で、metas.json があるかどうかを判定する材料として使えるので、version 12 かそれ以前かを判定できそうです

onnxruntime 版コアの自動判定のみをサポートする場合

• onnxruntime 版のみに絞って考えると、コア名によって version 12 かそれ以前かを判別できるため、コアの initialize 関数に渡す引数をそれで切り替えることができる
• libtorch 版コアを使用したい場合は、libtorch 版コアのパスのリストを別途渡すようなオプションを生やすなど、何らかの明示的指定の手段を用意する必要がある

[takana-v]

コア名から libtorch or onnxruntime 版を判定することが不可能であるため、ヒントとなる別の情報を何らかの方法で追加する必要がある

ちょっと不確定かもしれませんが、dllなどがあるディレクトリ内にmetas.jsonや*.binがある場合はlibtorch版、としてもいいかもしれません。

• コア名にアーキテクチャなどが入っていたら0.10~0.11
• ディレクトリ内にmetas.jsonがあったらlibtorch版（0.9以前）
• 無かったら0.12以降

[PickledChair]

なるほど、いいアイデアですね！ 各条件を表にすると以下のような感じですね。

バージョン	<= 0.9	libtorch 版 ←→ onnxruntime 版	0.10, 0.11	>= 0.12
コア名末尾のアーキテクチャ名	❌	-	⭕️	❌
metas.json の存在	⭕️	-	⭕️	❌

そして挙げていただいた以下の順に判定すると、確かに３種類のコアを判別できそうです。

• コア名にアーキテクチャなどが入っていたら0.10~0.11
• ディレクトリ内にmetas.jsonがあったらlibtorch版（0.9以前）
• 無かったら0.12以降

[Hiroshiba]

なるほです！！！　まとめありがとうございます！！

とりあえず今までのコードも活用できそうで、かつ名前統一もできてライブラリをより簡単に利用できて良いなと感じました。
こちらのPRは適用する方針でどうでしょう👀

• Libcoreなどをリネームしないようにする voicevox_core#114

（製品版もビルドする準備があるので、適用され次第ビルドしてみようかなと思っています。）

[PickledChair]

こちらのPRは適用する方針でどうでしょう👀

いいと思います！

エンジン側の対応は、他に取り組んでいる方がいなければ自分がやってみようと思っています。 @takana-v さんは取り組んでいらっしゃいますか？

[takana-v]

取り組んでいないのでよろしくお願いします🙇

[Hiroshiba]

製品版のコアのビルドが完了しましたのでご報告です！
https://github.com/VOICEVOX/voicevox_core/releases/tag/0.12.0-preview.2