Rustから直接VOICEVOX Coreを使いたい

[CrafterKina]

内容

クレートとして整備し、RustからFFIを経ずにVOICEVOX COREを利用できるようにする。

Pros 良くなる点

VOICEVOX Core内で扱われているものが、Cのエラー表現などを経ずに扱えるようになる。
RustからVOICEVOX Coreを扱う人が増えれば、必然的にRustでVOICEVOX Coreに貢献できる人が増える。

Cons 悪くなる点

実現方法

モデルの読み込み部分だけ(あるいはCやPython同様インターフェース部分以外)を別ライブラリ化し、製品版とダミーで切り分けられるようにする。
rlib形式などで直接扱う他のlibと同じ方法で頒布することもできそうだが、Rustにはヘッダファイルに該当するものがないため、エディタの補完機能などの面で厳しそうなため。

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

その他

モデルの外部化やライブラリ構成を変えるプロジェクトが進行中なので、裏で検討済みっぽそうではあるもののRustからの利用を考慮する予定があるのかを問い合わせたい。
あんまりRustに詳しいわけではないので、実現方法の間違い改善点や、そもそも何もしなくてもRustから簡単に扱えるよというのがあるかもしれない。

[Hiroshiba]

issue作成ありがとうございます！！

RustからVOICEVOX Coreを扱う人が増えれば、必然的にRustでVOICEVOX Coreに貢献できる人が増える。

という視点面白いですね！

Rust対応はちゃんとした予定がありませんが、もしモデルを読み込めるようになると普通に利用できるようになるかもです。

VOICEVOXはプログラミングにそこまで詳しくない方が趣味で使う人が多い想定で、Rustはあまりメジャーな言語ではないため需要はあまり高くないだろうなとは思います。
もし簡単に提供できるなら面白いかもと思いました！

[Hiroshiba]

少なくとも @CrafterKina さんが作ってくださるならウェルカムという感じかもです！！
VOICEVOX COREはonnxruntimeのRustラッパーに依存していて、まさにその機構が近そうなので参考になるのかなと思いました！
https://github.com/VOICEVOX/onnxruntime-rs/tree/master/onnxruntime-sys
（ビルドしたdllなどを読むラッパーを作る感じを想像しています。）

[CrafterKina]

個人的にはdllの配布に加えてrlibもしくは(cdylibではなくdylibで生成される)dllとともにヘッダファイルの代わりの薄いRustファイルがついてくるみたいなのを想像していました。一旦Cの表現にしたものをRustの表現にするのはすごい二度手間を感じるところではあるので。
ただ、どこまでrlibなどが使いやすいものかまでは調べているわけではないので、FFIをVOICEVOX側で持ってもらうほうがインターフェースが統一されてわかりやすくなるのかもしれませんが、よくわかりません。

[Hiroshiba]

Rustに詳しくないのですが、crateとして配布できるならとりあえず何でも良いのかなという気持ちです！
なので実現可能であればその形でも大丈夫なのかなと！やりやすい形で進めて頂ければ！！

[qryxip]

rlib/dylibはABIの保証が無いため、OSの他にRustのバージョンごとに配布しなければならないと思います。それをなんとかするためのライブラリはあるのですが、 cdylibからの再翻訳と比べてお手軽とは言えない気がします。

先程のonnxruntime-rsの例ですが、libloadingを使うのはどうでしょうか? 現在onnxruntime本家に出されているRust API追加のPRではそのような動きがあります。

[qryxip]

あ、勘違いしていたのですがabi_stableってlibloadingと似た感じのものなんですね。

[qryxip]

ただ手間はやはりかかるため、cdylibとrlibの両方を提供する理由としては弱い気もします。
(voicevox_coreクレートを結構改造する必要があると思います)

[Hiroshiba]

@qryxip さんありがとうございます、いつも助かってます🙇‍♂️

ちなみにonnxruntimeはディープラーニングしたものをいい感じに使えるライブラリで、マイクロソフト製でかなりしっかりしてるのでこのリポジトリでもいろいろ参考にしてます。

[CrafterKina]

全体のrlib化が難しいのであれば、(製品版とコードが異なる部分である？)モデルの読み込み部だけcdylibにしてそれをRustから使う方式に変更するというのがあんまり表現を行ったり来たりしなくなる方法ではありそうですね。
ただ、そもそも現在C向けに公開されているインターフェース以外は外部からアクセスすることを想定していない(製品版とOSS版で異なる可能性がある、テスト用途などのために公開されているなど)とも思うので、であればそこまではC向けのインターフェースと統一してlibloadingなどで読み込みRust向けのインターフェースとするのが結局丸いのかもしれませんね。一旦その方向で考えてみます。

[PickledChair]

私もこの Issue の趣旨と同じようなことを以前個人的に考えたことがあったのですが、以下のような考察をした上で、これについて議論を開始するのは早すぎると考えたため、提案を見合わせていました。

「実現方法」で言及していただいている

モデルの読み込み部分だけ(あるいはCやPython同様インターフェース部分以外)を別ライブラリ化し、製品版とダミーで切り分けられるようにする。

が一つのハードルになっています。

このリポジトリで OSS として公開されている部分とは別に、配布されている製品版では暗号化された音声合成モデルを復号する処理を行なっています。提案されている方法は、この処理を担当する部分を別ライブラリ化して、OSS 版と製品版で差し替え可能にする、というものだと理解しています。

ただし、暗号化されたモデルを復号したあと、ヒープにあるそのデータへのポインタが外部に漏れないようにするために、その別ライブラリ化した部分に onnxruntime を使用している処理を全て移す必要がありそうだと考えています。つまり、モデルをロードする部分のみをインターフェースとして切り出すだけでは足りず、Status 構造体が関係している処理を丸ごと切り出す必要があるということです。これを共有ライブラリ等に切り出して、動的に読み込めるようにする感じになると思います。onnxruntime はこちらの切り出されたライブラリの方にのみリンクされるようになりそうです。このライブラリはモデルのロードに加えて、onnxruntime を用いた処理を wrap した最低限のインターフェースを提供します（同じ目的を達成できるなら、他の方法をとっても良さそうです。）

（ @Hiroshiba さんが

Rust対応はちゃんとした予定がありませんが、もしモデルを読み込めるようになると普通に利用できるようになるかもです。

と #388 (comment) で言及されていますが、その仕組みでは足りないと考えている、ということです）

現在は voicevox_core の設計が大きく変わっている途中であり、これ以上の大きな変更を持ち込むと混乱が大きくなると考えていたため、特に提案はしてきませんでした。

ただ、（Prosで触れられている通り）Rust コードから voicevox_core を利用しやすくすることは、Rust を使用する開発者がこのプロジェクトに貢献するモチベーションを高めることにつながると思うので、リソースを割く価値のある取り組みにはなりそうだと思っています。