ソフトウェア

クライアントライブラリは Rust で実装されており, 各言語バインディングはそれを包む形で提供される.

クレート構成

クレート依存関係

クレート	役割
autd3-rs-core	基盤層. geometry / value / params / protocol と通信の観測型 (bus).
autd3-rs	クライアント本体
autd3-rs-pattern	位相・振幅パターンの計算 (単一焦点等).
autd3-rs-pattern-holo	多焦点音場再構成. 理論は理論と考察を参照.
autd3-rs-modulation	AM 波形計算.
autd3-rs-firmware-emulator	実 CPU ファームウェアのクレート (autd3-cpu-fw) をリンクし, Rust による FPGA エミュレータと組み合わせる

タスクモデル

Client は, 送信も受信も呼び出し側のタスクがその場で行う. 持つタスクは生存確認の周期送信 (TransportOption::heartbeat_interval を指定したときだけ) の 1 本である.

タスクモデル

• 送信: send / send_streaming / read_state を呼んだタスクがその場で全デバイスへ送る. tokio を前提とする.
• 受信: 同じ呼び出しの中で, 送ったフレームの msg_id に一致する返信を全デバイスぶん集める. 期限は持たない (上限はユーザーが付ける). 返信を読むメソッドは &mut self で, 同時に 1 つしか動かない. 生存確認のタスクは送るだけで読まない (返信は次の呼び出しの先頭で捨てる).

Client の内部の送受信層 (controller/) が持つのは Geometry・通信層の Channel (udp/channel.rs, crate 内部)・msg_id の採番 (AtomicU16)・デバイス時刻の推定 (DeviceClock. デバイス時刻の推定を参照) だけである. Channel は普通の UDP ソケットで各デバイスへデータグラムを 1 つずつ送り, 届いた返信を 1 つずつ返す口だけを持ち, デバイスの状態は持たない. 返信待ちの上限・途絶の判定はユーザーが決める. Link のような差し替え可能な通信路の抽象は無い.

ユーザー API からデバイスまで

ユーザーが渡したコマンドは, フレーム列へ実体化されたうえで send を呼んだタスクから送出される (返信を待たずに送ってよいのは MAX_INFLIGHT (= 7) フレームまで).

コマンドの流れ

バインディング

言語	方式	備考
Rust	-	本体.
Python	PyO3 + maturin	C FFI を経由せず Rust API を直接ラップする.
C# / Unity	C FFI + P/Invoke	bindings/ffi/ の cdylib 群を参照する.

bindings/ffi/ は言語中立な C ABI の cdylib 群であり, クレート毎に分かれている. 不透明ハンドルと共有 ABI 契約は autd3-ffi-abi が定義する.

ビルド

開発タスクはすべて cargo xtask で実行する.

cargo xtask rust build   # ワークスペース全体ビルド
cargo xtask rust test    # 全テスト
cargo xtask rust lint    # clippy --all-targets -- -D warnings
cargo xtask rust format  # rustfmt --check