-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
複数コアを利用可能にする #3
Comments
現状(0.9.3)だと、コアを1つのプロセスで複数loadすることができないのがかなり厄介です。
|
例えば0.9.3のコアと0.8.0のコアがあったとして、二つともengineからimportするのは難しいのでしょうか |
2つともengineからimportするのが難しいと考えています。 |
具体的な障壁はどこになるのでしょうか |
具体的な障壁を洗い出すところからになると思います。 |
手が空いているので挑戦してみようと思います。 |
ありがとうございます!! |
このリポジトリだけできませんね... |
writeになっていませんでした・・・ assignしました、よろしくおねがいします!! |
VOICEVOX/voicevox_engine#214 とコンフリクトしそうなので、マージされ次第進めたいと思います。 |
windowsでは、core.zipを解凍したものに |
なるほど、つまりバージョンXのcoreを動かすにはバージョンXのcore.pydが必要だけど、core.zipに梱包されていないということでしょうか。
core.pyx、つまりコアのインターフェイスが互換性なく変更されるときは、きっとエンジン側の処理も変わっており、過去のコアはそもそも使えなくなりそうかもです。 どうでしょう・・・? |
過去バージョンはどこまで対応すればいいでしょう?
などで問題が発生するかもしれません。 |
インターフェイスが変わっているととても大変ですが、たしか一応インターフェイスは変わっていないんですよね。 所管として、キャラクターの追加には対応できるようになっていると便利そうです。 |
ちょっと詰まったので...
https://github.com/VOICEVOX/voicevox_engine/compare/master...takana-v:multi-core?expand=1 |
エラー内容的に、libtorchがモデルをロードする際のzip展開に失敗していそうです。 これは当てずっぽうの推測ですが、テストで使われているコアのdllと.binのバージョンが揃っていない可能性があるかもです。 |
バイナリ化した場合、sys.pathを設定してもデフォルトのコアモジュールが読み込まれている気がします。 解決策がちょっと思いつきませんでした。 |
Linux版ですが、以下のようなプログラムで複数バージョンのcoreモジュールを扱えそうでした。 Ubuntu 20.04、Python 3.7.12、製品版0.7.5と0.8.2同梱のコアモジュール(core.so)とコアライブラリ(libcore.so、CPU版)で試しました。 # main.py
# force nuitka to include numpy
import numpy as np
# ---
from pathlib import Path
import importlib.util as imu
from ctypes import cdll
use_gpu = False
# VOICEVOX 0.7.5
# voicevox_dir (Python module directory)
core_a_root = Path('~/apps/voicevox_cpu-0.7.5/squashfs-root').expanduser()
# preload linked shared library
cdll.LoadLibrary(core_a_root / 'libcore.so')
# load core module
core_a_spec = imu.spec_from_file_location('core', core_a_root / 'core.so')
core_a = imu.module_from_spec(core_a_spec)
core_a_spec.loader.exec_module(core_a)
# voicelib_dir (*.bin, metas.json)
print(core_a_root)
core_a.initialize(core_a_root.as_posix() + '/', use_gpu)
print(core_a.metas())
# VOICEVOX 0.8.2
# voicevox_dir (Python module directory)
core_b_root = Path('~/apps/voicevox_cpu-0.8.2/squashfs-root').expanduser()
# preload linked shared library
cdll.LoadLibrary(core_b_root / 'libcore.so')
# load core module
core_b_spec = imu.spec_from_file_location('core', core_b_root / 'core.so')
core_b = imu.module_from_spec(core_b_spec)
core_b_spec.loader.exec_module(core_b)
# voicelib_dir (*.bin, metas.json)
print(core_b_root)
core_b.initialize(core_b_root.as_posix() + '/', use_gpu)
print(core_b.metas()) # source
python3 main.py
# binary
python3 -m nuitka --standalone --plugin-enable=numpy --follow-import-to=numpy --follow-imports --no-prefer-source-code main.py
$ ./main.dist/main
***/apps/voicevox_cpu-0.7.5/squashfs-root
[{"name":"四国めたん","speaker_uuid":"7ffcb7ce-00ec-4bdc-82cd-45a8889e43ff","styles":[{"id":0,"name":"あまあま"},{"id":2,"name":"ノーマル"},{"id":4,"name":"セクシー"},{"id":6,"name":"ツンツン"}],"version":"0.7.4"},{"name":"ずんだもん","speaker_uuid":"388f246b-8c41-4ac1-8e2d-5d79f3ff56d9","styles":[{"id":1,"name":"あまあま"},{"id":3,"name":"ノーマル"},{"id":5,"name":"セクシー"},{"id":7,"name":"ツンツン"}],"version":"0.7.4"}]
***/apps/voicevox_cpu-0.8.2/squashfs-root
[{"name":"四国めたん","speaker_uuid":"7ffcb7ce-00ec-4bdc-82cd-45a8889e43ff","styles":[{"id":0,"name":"あまあま"},{"id":2,"name":"ノーマル"},{"id":4,"name":"セクシー"},{"id":6,"name":"ツンツン"}],"version":"0.8.0"},{"name":"ずんだもん","speaker_uuid":"388f246b-8c41-4ac1-8e2d-5d79f3ff56d9","styles":[{"id":1,"name":"あまあま"},{"id":3,"name":"ノーマル"},{"id":5,"name":"セクシー"},{"id":7,"name":"ツンツン"}],"version":"0.8.0"}]
下から |
私はdllのラッパーを書いて実装してみました。 @aoirint の実装はコード量が少なくて済むので良さそうに感じました。 |
AppImageは実行時は/tmp以下にマウントされる(展開されたように見える)ようで、extract不要で動きます。 |
@aoirint の実装と私の実装、どちらでも動きそうですね。 |
どういう違いがあるのかわかっていませんでしたが、cython等で作った であれば、仮に将来coreのインターフェイスが変わった場合、takana-vさんの案だとインターフェイスの分だけ実装や分岐が必要になる一方、aoirintさんの方だと統一で書けるので、aoirintさんの案だと将来的に楽なのかもと感じました。 ちなみに、あまり良くわかってないのですが、numpyへの型変換とかもやってくれるんでしょうか。 |
そうですね、私の実装はcoreのpython実装みたいな感じです。 とりあえずaoirintさんの実装と私の実装は1つ大きな違いがあることに気が付きました。 aoirintさんの方はVOICEVOXのAppImage(やwindows版だとzip版)があれば動く感じです。 私の方は、VOICEVOX/voicevox_coreで配布されているcore.zipとlibtorchのライブラリが必要です。 Mac版では過去コア対応は0.10以降のみになってしまいますが、そもそも過去バージョンを使ったことのあるMacユーザーはほとんどいないので問題ないかと思います。 |
おお、なるほどです!! |
core.zipに格納されているC++の共有ライブラリ(core.dll, libcore.so, libcore.dylib)をPythonモジュールとして扱うためのラッパー実装を、ENGINE側に持つか、CORE側に持つかということで考えていました。 いまは、Cython実装が(exampleとして)COREのリポジトリにあるので、CORE側が持っています(自動ビルドではこのexampleを使っている)。 takana-vさんがENGINE側に持つ実装(ctypes)を試しそうだったので、 個人的には、ビルド済みのPythonモジュールはPythonバージョンやプラットフォームへの依存があって扱いにくいので、ENGINE側にラッパーを持つtakana-vさんの実装の方がいいかなと感じています。 VOICEVOXソフトウェアは容量が大きいので、core.zipだけで動作するならば、ほぼ必要最小限のファイルだけダウンロードすれば済むのもよさそうです。 ただライセンス的には、Pythonラッパーの実装がMIT LicenseからLGPLになるので、再利用しにくくなるかもと思いました。 (エンジン上では最新のコアも過去のコアも共通の仕組みで扱うことになると思っています) |
なるほどです、よくわかりました!! 僕もENGINE側に実装を持つのが良いのかなと感じました。 |
とりあえずエンジン側での実装です。 それのバイナリです。 現時点では このままだとライセンスがLGPLになるので使いにくいですね... |
onnx版を見てみると2つ関数が追加されているので、cython実装のcore.pydなどはlibtorch版で使いまわせない可能性が高いです。 チェックはできていませんがonnx版対応しました。 |
とりあえずctypes実装についての案です。
どれが良さそうでしょう? @Hiroshiba |
とりあえずエンジンに実装してしまって、切り出せそうならcoreに置いたり、ライブラリ化したりするのが良いのかなと思いました! |
@takana-v さんのプルリクエストがマージされ、過去バージョンのコアが使えるようになりました!!!本当にありがとうございます!! 一旦ここで、実際のユースケースを考えながら、残りの課題があるかを考えてみます。 |
はじめに、実際にユーザーが過去のコアを使いたくなったときの工程です。
あとは、サードパーティ向けの案内もあれば、選択UIを用意してくださるかもしれません。
他にですが、近い将来やりたいなと思っていることの1つに、高速版と高品質版のコアを作りたいと思っています。
とりあえず意見もらえると嬉しいです!! |
またtakana-vさんにお願いできればと思ってたのですが、takana-vさんあれですね辞書プロジェクトもアサインされてますね。。。 @PickledChair さん、どうでしょう・・・?👀 |
自分が対応できるかどうか考えてみたのですが、いくつかの理由から、他の適任者をまずは考えていただいた方が良いのではないかと思いました(申し訳ないです)。
上記のように理由を述べましたが、認識に誤りがあればご指摘をお願いします。また、上記の理由を考慮しても自分が担当する方が VOICEVOX プロジェクト的に良いという判断がなされた場合は、改めて自分が複数コア対応に関わることを検討したいと思います。 |
@PickledChair なるほどです!! まずエンジンに関してですが、たしかに過去のコアを持った過去のエンジンを用意する手も考えられると思います。 不慣れなこと、お忙しいかもしれないこと、とてもよくわかりました。 あ、でしたら、独立している |
そうだったんですね! そこまで見通せていませんでした。複数コア対応の方が早くに完了しそうなんですね。先にお伝えした通り、今すぐに自分が率先してやる余裕はなさそうなのですが、協力できる範囲でお手伝いできればと思います。
(Web 系でなく)Python であればまだ馴染みがあるので、こちらのみであれば比較的見通しが立ちやすい印象でした。エディタについても、内蔵エンジンのエディション切り替え設定くらいであれば取り組めそうな気がしています。機能追加の練習にもなると思ったので、担当したいと思います(これまで自分がしてきたのはビルド周りか機能修正のコントリビュートのみでした)。本腰を入れられるのは2月2週目くらいからになりそうですが……。 |
ありがとうございます!! では引き続き、複数コアをエディタで活用するメインの方を募集をしています・・・! |
加えて、「あるキャラだけバージョンアップで増える」みたいなこともありそうです。 |
こちら、キャラクターごとにモデルが分けられるようになった関係で、そもそもアップデートされる頻度が下がりました。 そのため重要度が下がったので、優先度を少し下げたいと思います。 |
複数コアの需要ですが、ユーザーの方々の要望を聞いていると、キャラクターごとに過去バージョンを使えると嬉しいのかなと思いました。 下記issueにて、取り組んでくださる方を募集しています。もしよければ・・・! |
そろそろ音声ライブラリの刷新を考え始めています。 まずは議論ということで・・・一旦考えている設計を書いてみます。 やりたいこと必須:過去のバージョンの音声の利用 考えてる実装方針エンジンからいろんなバージョンのコアをダウンロードする。 詳細ダウンロード
エディタとの連携
管理
懸念点
とりあえず、必須の「過去のバージョンの音声の利用」だけであればそんなに破綻のない設計だと思っています。 |
エンジン実装voicevox_engine#303 にて実装検討が完了。低コストで実装可能と結論。 |
現在「エディション」についての状況を説明します 🙇 もともとは高品質版に取り組むつもりがかなりありました。 このタイミングでエディション実装の機運が一旦後回しになっていました。 現状はエディションに関して何か注力している方針はありません。 このissueを一旦クローズするべきかどうかはちょっとまだ判断できてません。とりあえず保留させていただければ・・・ 🙇 |
キャラクターを追加したり、性能をあげようとするたびに、コアのバージョンアップが入ります。
コアが変わるとどうしても声の調整感が変わってしまい、ユーザーにとって少しストレスになってしまいます。
(ユーザーが離れる理由になってしまうのが一番の問題です)
コアを入れ替え可能にすれば、過去のコアも使えるようになります。
結構急ぎめで導入したい機能です。
おそらくコア・エンジン・エディタ全てで対応が必要なため、プロジェクトとして扱っています。
The text was updated successfully, but these errors were encountered: