13-Oct-2024
[折角PulseAudioを触ったので]

リモートスピーカーなるものをやってみようかと。PulseAudioで簡易リモート再生に書いてあることを自分でもやってみた、というだけの話なんですけど。

サーバ側(音が出る方)
~/.config/pulse/cookieによるアクセス制御はせず、/etc/pulse/default.paにload-module module-native-protocol-tcp auth-anonymous=trueを記述して、pulseaudioを実行(デーモン化はお好みで)
クライアント側
PULSE_SERVER=<PulseAudioサーバのIPアドレス> paplay --raw /dev/urandom

sndioについては15-Oct-2022にさらっと書いていますが、まとめ直すと…

サーバ側(音が出る方)
/etc/rc.conf.localにsndiod_flags="-L <待ち受け用のIPアドレス> -f rsnd/0" ※-fオプションでsndioの管理下に置くデバイスについては各自の環境に合わせて記述してください
クライアント側
aucat -f snd@<sndioサーバのIPアドレス>/0 -i /dev/urandom

sndioのアクセス制御とはちょっと違うなーとか、snd@<IP address>/0の/0の部分でサーバ側の出力デバイス変えられるのかなー(未確認)とか、PulseAudioと比較してみると色々違うものなんですね。どちらを使うにせよ、リモートスピーカーはそんなに難しくないということは言えそうです。

そういえば、OpenBSDのPulseAudio→sndioモジュール、入出力先のsndioデバイスはどう指定するのか気になっていたんですがOpenBSDGuy/pulseaudio-module-sndioに方法が書いてありますね。/etc/default.paに、load-module module-sndio device="snd/0"みたいな形で指定すれば良さそうです(他にも色々な引数があります)。56.6kg(17:05)

12-Oct-2024
[どうにか(3)]

yamvoiceにsndio対応がとりあえず入ったので、PulseAudio対応も実験的に入れてみました。WSL2だとPulseAudio越しなら音が鳴るらしいというのがその理由。とはいえ、WSL2のALSAはデフォルトの入出力先がPulseAudioなので、PulseAudio対応は不要だった(原典のmvoiceで十分対応できる)というオチ。そういえばOpenBSD向けのalsa-libもPulseAudio plugin使ってPulseAudioに回してましたね…

まあWindowsで使わなかったとしてもPulseAudioはIllumos(Solaris), OSXにも対応しているらしいのでそっち方面で役に立てば良いんじゃないんですかね。PulseAudioの素のAPIがやたらと複雑怪奇なのに対し(defaultデバイスのみの対応としたのはデバイス名一覧の取得がこんなコードになるという理由による)、Simple APIだと雑に書いても音が鳴ることが分かっただけでも十分な収穫だし。

yamvoiceはここまでにして、次にやるべきことをやりましょう…56.0kg(22:40)

05-Oct-2024
[どうにか(2)]

mvoiceのPRに投げた修正点を、立ち上げたフォークであるyamvoiceに放り込んでREADME.mdを書き直すところまではどうにか。

あとはALSA依存部分を切り離してsndio対応部分を書くことになるのだけど、この切り離しがちょっと面倒そう。C++で書かれているので、API非依存部分を基底クラスにしてAPI毎の派生クラスを作るのが定石とはいえ、基底クラスに「std::async(派生先のオブジェクト)」というコードを書くのはどうもダメらしい(派生クラスに「std::async(派生クラス内のオブジェクト)」を書いて、これを基底クラスから呼ぶのもダメだった)。

いくらなんでもできないことはないはずだし、自分の書き方間違ってるよね…?と思っているのですが、悩んでいる時間も勿体ないので今回は安直に分解することにしました。別に複数のAPIに同時に対応して、アプリケーション側の設定で動的に切り替える必要もないですし。

という訳で、ゆるゆるやってます。57.2kg(23:30)