SVX日記

　客のための商品を作っているんだろう？ならば「理由はよくわからないが、適当にやったらできた」というレベルの仕組みをコネ上げんじゃねぇよ。それは「適当にググッて見つけたコードを使う」のと同じだぜ。最近は「適当にAIに聞いて出てきたコードを使う」というのが良いことのように語られているが、そのコードに対する責任を負うのはアナタなんですよ。理解できてないものは使うんじゃねぇよ。売りもんだろ？

　恐ろしいことに「そんな作りはおかしい」と指摘すると「もうテストまで終わっているので変えられない」などと返されるパターンがある。それが、稀ではなく、頻繁にある。そんなの知るかよ。クソアプリのためにOS側を直せって？正気か？設計者を断罪すんだよ。バカの相手はつかれる。

　つうわけで、Linuxのサウンド機能はそれなりにややこしい。いつもなら、ここに理解をまとめるところだが、まとめるのが難しいほどにややこしい。歴史的な経緯が積み重なりまくっているので、アッチやコッチのサイトの情報を浴びているうちに、なんとなくわかってくる感じだ。

　とはいえ「客のための商品を作っている」エンジニアならそれくらいやれよ。理解できていない自分を自覚しろ。相手は太客だろうよ。興味ねぇならエンジニアやめろ。恥だ。つうか、恥ずかしくないエンジニアって、ウチに何人いるんかな？そんなレベルで作ってるシステムなんだから、そらトラブるわ。でも、どこの会社、どこの業界もそうなんだろうな。建設業界でも手抜き工事はあるからね。それでも、そう簡単には表面化しないものなのだろう。気づかないけど、そういうクソなシステムに囲まれているのが我々の日常なのです。

　というわけで自分も、ちゃんと理解できていない自分を自覚して、改めてLinuxのサウンド機能についての理解を進めた。過去にも断片的に書いているが、読み返しても大きくは間違っていないな。改めてまとめると、こういうことだな。

・ある時「Sound Blaster Pro」がデファクトスタンダードになり、PCM音源以外は過去のものになった
・OSS(Open Sound System)が登場、PCMの再生/録音が可能になった
・ALSA(Advanced Linux Sound Architecture)が登場、OSSを置き換えた
・ALSAには、OSSのエミュレーション機能もあり、OSS向けのアプリも動かせる
・PulseAudioが登場、ソフトウェアミキサにより、複数のアプリの同時発声が可能になった
・逆に言うとOSS/ALSAは、あるアプリが音を出すと、他のアプリは音を出せなかった
・PulseAudioには、ALSA/OSSのエミュレーション機能もあり、ALSA/OSS向けのアプリも動かせる

　で、主にPulseAudioについて調べ始めたのだが、手元のFedoraではPulseAudioが動いていなかった。代わりにPipeWireというものが動いている。PulseAudioを代替するもののようだ。加えると、こういうことだな。

・PipeWireが登場、PulseAudioを置き換えた
・PipeWireには、PulseAudioのエミュレーション機能もあり、PulseAudio向けのアプリも動かせる

　理解に重要なのは「置き換え」「エミュレーション」の関係である。機能には様々な組み合わせがある/ないことの理解だ。「ゲッターロボ」や「Gアーマー」程度には組み合わせは複雑である。時代とともにこう変化してきたのだ。たぶん。

OSSアプリ → OSS
　↓
ALSAアプリ → ALSA
OSSアプリ → OSSエミュ(ALSAの) → ALSA
　↓
PulseAudioアプリ → PulseAudio → ALSA
ALSAアプリ → ALSAエミュ(PulseAudioの) → PulseAudio → ALSA
OSSアプリ → OSSエミュ(PulseAudioの) → PulseAudio → ALSA
　↓
PulseAudioアプリ → PulseAudioエミュ(PipeWireの) → PipeWire → ALSA
ALSAアプリ → ALSAエミュ(PipeWireの) → PipeWire → ALSA
OSSアプリ → OSSエミュ(PulseAudioの) → PulseAudioエミュ(PipeWireの) → PipeWire → ALSA

　ほかにもPortAudioとかJACKとかあるようだが、上記が理解できているならば、ちょっと調べればどこに位置するものかわかるだろう。

　 aplayというコマンドを使うなら、当然それがどういうものか理解しておく必要がある。aplayはalsa-utilsに含まれるものであるからALSAアプリである。だが、普通に使うとALSAエミュ(最近ならPipeWireの、ちょっと前ならPulseAudioの)を経由してALSAから発声される(ように設定されている)。これによって、複数のaplayが並行実行できるわけだ。しかし、いまでも直接にALSAに出力することもできて、その場合は複数のaplayは並行実行できない。それが元来のaplayの姿である。

　一方で、paplayというコマンドはpulseaudio-utilsに含まれるPulseAudioアプリである。デスクトップアプリとして音を出すならば、他のアプリと衝突しないようpaplayを使うのが正しい。

　さて、そんなことをやっていたら、音声キャプチャをする必要があったことを思い出した。ヴォーカル修行で歌いたい曲をYouTubeから得るためである。ちょっと前まではyoutube-dlが使えたのだが、最近は使えなくなってしまっている。ラインケーブルでPCMレコーダをつないで録音するかなぁ……と思っていたのだが、やっぱりデジタルキャプチャしたい。

　ちょっと前には上に書いたほどLinuxのサウンド機能について理解していなくて、JACKを導入したりして試行錯誤していたのだが、わかってしまえば簡単だった。PipeWireの録音ツール「pw-record」で一発だ。

$ pw-record --target 55 pcm.wav

　 55というのはノードのIDで「pw-top」で調べられる。スピーカの直前でキャプチャするイメージだ。実行しておいて、YouTubeで課題曲を再生すればいい。アラート音を出すと一緒に録音されてしまうので、録音中はお静かに。おかんの「ご飯だよ〜」は、セーフだが。

　 PipeWireでなくPulseAudio環境なら、録音ツール「parecord」を使う。

$ parecord -d 55 pcm.wav

　同じく55というのはノードのIDで「pactl list short」で調べられる。キャプチャしたpcm.wavは、周囲に不要な部分があるであろうから、例のcccdctで切って作業完了である。

　つうわけで、趣味であっても、仕事ならなおさら、わからんことがあったなら学ぶべきだ。頭があんだからさ。いつまでもスワップが悪だとか凝り固まってんじゃねぇよ。売ってんのは技術なんだぜ。訊くのもいいが、せめて正しく理解する。当たり前だろ？

[ツッコミを入れる]

2025-02-17(Mon) シン・チープなDTMアプリ

　 Linuxのサウンド機能についておさらいしたところで、だーいぶ以前に作った自作のDTMスイート「CUIck DTM suite」を引っ張り出してみることにした。当時はまだWindozeを使ってたので、Cygwin環境に向けて書いたものだ。何度か何度か何度かお色直しして使い続けているが、いまでも使えるものだろうか？

　「CUIck DTM suite」には「melod」という発声デーモンがあって「konk」というアプリを組み合わせることで「PCのキーボード」が「楽器のキーボード」と化す。過去にはソレ用にこんな風に塗り分けたりしてた頃もあった。

　「melod」は「/dev/dsp」にPCM波形を書き込み続けるデーモンで、当時はよく考えずに作ったものなのだが、これはOSS(Open Sound System)アプリだったわけだ。

　まずは、前回まとめたところの、以下の経路で使ってみる。

OSSアプリ → OSSエミュ(PulseAudioの) → PulseAudioエミュ(PipeWireの) → PipeWire → ALSA

　 PulseAudioのOSSエミュレータ「padsp」を噛ませて起動するわけだ。

$ padsp ./melod

　通常の環境には/dev/dspは存在しないのだが、padspを噛ませた中の環境には/dev/dspが出現するので、それを経由してPulseAudio……ではなく、PipeWireを経てALSAから鳴るわけだ。実際、アッサリと鳴った。よく考えてみれば、エラく回りクドいことをやってたんだな。

　しかし、別にその経路が唯一というわけではない。OSSエミュレータはALSAからも提供されているのだ。カーネルモジュールの形になっており、通常はロードされていないが、ロードすりゃ使える。

# modprobe snd_pcm_oss

　これにより/dev/dspではないが、/dev/dsp1, /dev/dsp2が出現する。/dev/dsp1がノートPC本体のデバイス、/dev/dsp2はドックのデバイスを指すものだ。これを使えば、以下の経路を使うことになる。

OSSアプリ → OSSエミュ(ALSAの) → ALSA

　 melodの/dev/dspを/dev/dsp1に書き換えて起動してみる。

$ ./melod

　んが、動かん。音を鳴らそうとした瞬間に落ちる。どうもfragment(バッファ)のサイズが足りないらしい。なんで？

　 fragmentのサイズを調べようと思って、ioctlでSNDCTL_DSP_GETBLKSIZEを発行してみる。どうでもいいけど、ioctlってどこかに仕様がまとめられていたりしないの？カーネルのコード読むほかないのかしらん。

    x = [0].pack('i*')
    p dsp.ioctl(0xc0045004, x)                                  # SNDCTL_DSP_GETBLKSIZE
    printf("%04x\n", x.unpack('i*')[0])

　 55hって値が返ってきたが、なんのこっちゃ……って、アレ？なんか音が出るようになっているのだけれど。なんで!?

    x = [0, 0, 0, 0].pack('i*')
    p dsp.ioctl(0x8010500c, x)                                  # SNDCTL_DSP_GETOSPACE
    printf("%04x %04x %04x %04x\n", *(x.unpack('i*')))

0020 0020 0080 1000
 ↓
0020 0020 0300 6000

　事前にSNDCTL_DSP_GETBLKSIZEを実行すると、fragmentサイズとして55hが返ってくるのだが、なぜかその後のfragmentサイズは6倍(80h->300h)になっている……ワケワカラン。まぁ、鳴ったからいいけど。当然ながら、この経路でALSAを使う場合、デバイスは専有されるので複数起動することはできない。

$ ./melod
./melod:26:in `initialize': Device or resource busy @ rb_sysopen - /dev/dsp1 (Errno::EBUSY)

　しかし、なにより驚いたのは、padspの実体がシェルスクリプトになっていたことだ。以前はバイナリだったんだがな。

　結局、この辺りは「いつまでも工事中」ということなんだろうな。ベストを求めて、常に発展途上であり、使う時にはちゃんと最新事情を調べて理解することが重要ということだ。前回と同じ結論だな。以上。解散。

[ツッコミを入れる]