粘ることRaspberry pi(Linux)のサウンド周りを調べ初め、alsaとかpulseaudioとかossとか
細かいところは置いておいて、インストール済みのパッケージの状態ではbusterでalsaとpulseaudioが両方入っていたossは見当たらない。。bullseyeではクリーンな状態ではないのですが、alsaとpulseaudioは入っていたが、ossはなし。stretchは多分alsaしか入ってなかったんじゃないかと。apt install pulseaudioなんて一昨日ぐらいに初めてたたいた気がする。
音が鳴らないなら、pulseaudioパッケージ入れればなるようになるかもと、installしたものの、何も設定しないとalsa側のarecordで結構致命的なレベルでエラーとなるようになってしまいました。慌ててパッケージをremove。
で、そこまで行く付くまでにサウンド関連の実装状態を知るように。
ossは別として、alsaもpulseaudioもドライバーから実装していてどちら側からも考慮されていて設定を行えば共存は可能で、どちらもデーモンなどでバックグラウンドで処理を行ってサウンド関連の制御を行っているということ。
個人的な感触ではalsaの方が若干粗削り感が強い。
で、どちらも何もしなくてもほぼそれなりに動作するっぽい。けど、stretchでは微妙。設定ファイルもあまり設定されていなかった。
そして振出しに戻り、alsaを調べてゆく。
alsaは最初にデバイスで設定できるスイッチやボリュームなどを操作してマスターボリュームのミュートも解除する必要がある場合があること。ここの点で出力側の話しかなかったが、入力側も同様の作りなのだと思う。（これが多分インストールしてから一回行えば大丈夫なのだろうと思う。alsaは起動時に設定状態を復元しているような部分があった。）
そしてそのキーであろうalsamixer。CUIで実装されたボリュームやスイッチがわかりやすく表示され操作できそうなのだが、残念なことにteratermを使っているとF1～F5を押すとプログラムが終了してしまうという。
これまでも何度も実行してteratermのキーマップを読み込み直してたのだが、どの定義マクロもすべてのファンクションキーが有効にならず、あまりまともに操作ができなかった。
そしてalsamixerで操作してもやはりマイクは有効にならなかった。
コンソールで直接操作するだけでよかったのかもしれないと思いつつも、teratermのヘルプを見ながらデフォルトで読み込まれるキーマップファイルKEYBOARD.CNFをF1～F5が有効になるFUNCTION.CNFを見ながら編集し、F1～F10のファンクションが使える状態で片っ端から操作した。マイクデバイスだけではなく、本体のイヤフォンジャックやHDMIの設定をmキーを押してON/OFFを切り替え、ボリューム系はスペースキーでミュートさせたり。F6キーでデバイスを切り替えたり、F1の情報を表示させたり…やれることは全てやった。
すると…何がトリガーなのかわからないまままた音が録音できるように。
途中で知った lsmod | grep '^snd' | column -t で表示される内容を見比べても音が出る前と出た後では状態は変わっていなかった。
書いている途中で寝落ちしたんですが、起きてから再起動かけたらどうなるのか気になってsudo rebootしてみました。すると…音が拾えなくｗまたかｗ
alsamixerでさんざんパラメータを変えたり情報を表示させても変わりません。まるで画面系のブラックボックステストの様ですｗ
bashhistoryを見てやれるだけのことはやった。が…まったく音が拾えません。
半ばあきらめて、alsa関連のパッケージを追加でインストールしてみてもやはり変わらず。再度pulseraudioをインストールしてみることに。
すると、前回はエラーでおかしかったのがpurgeしていたので環境がきれいになったためかrebootした後からなにやら絶好調。しかも音も拾えるように。
全くよくわからんｗ
で、動作確認をしてしばらくしてからreboot…音が… orz
なんかよくわからん状態だし、ここはシステムのアップグレードしかないという結論に。
ネットワーク関連も特に何もしていないraspberry piなのでbullseyeに一気にアップグレードさせました。
たまたま見つけたページがdist-upgradeをかけていたので同様に行ったわけですが、途中からエラーが。とどめのpythonスクリプト処理でもエラーが。大体１時間ぐらい？raspberry pi 2bで、なおかつクロックは低めの設定だったと思う。CPU温度は気温１８℃で最高２７℃台でした。
このまま再起動すると確実にやばそうなので、full-upgradeをかけてみました。現在はこちらが推奨されているようですね。
full-upgradeなのでかなり強烈に削除と追加を行うようで処理は時間がかかりました。途中画面が止まることが多々あったので余計に時間はかかっていますが153分程度かかっていました。
さらに念を押してエラーが出ないことを確認し、保留となってるパッケージがいくつかあるものの再起動はできそうです。
dhcpcd.confだけ確認して大丈夫そうなのでreboot
再起動後、早速arecord で録音してみると…「ぶぶぶぶっブチっ」とか処理落ちしてそうなサンプリングノイズが録音できました。
何度か繰り返した後、alsamixerで設定を確認すると、alsaのrestoreが機能しているためかボリュームやその他の機能が前に設定したままとなっているようでした。
おまじないで、全コントロールの操作とオン/オフを触りさらに再起動。
起動後にarecordで録音したところそれなりに音が拾えてそうな感じに。
アップグレード中、sambaの設定で文字化け画面しか見れなくとりあえず応答したのですが、そのまま残ってたようで外部からの確認作業がすぐにできました。
ほかに使ってそうな機能としては、肝心のmotionなのでそちらの設定を。今回はアップグレード途中で、パッケージメンテナの状態で更新するようにyで応答したので、ある意味bullseyeでのクリーンな実行環境になってるはず。
service motion statusで確認すると、やはりserviceファイルから起動していて、typeはsimpeでした。すげ変わっているmotion.confを今までのものに入れ替えて、今までdeamonモードをonにしていたのですが、offにして起動させました。
とりあえず、これでいいのですが、motionのビルド環境がそのままなので試しにstretchでビルドしたバイナリを実行してみると…ライブラリリンクエラーで起動すらしませんでしたｗ
なのでリビルドします。念のためコンパイルに必要なビルドパッケージを再度インストールしてみましたが、全て最新の状態になっていました。環境を整えてmakeしてmake installして、起動させてみると、問題なく動く様子。後で切り替えておこう。webcontrol画面の日本語が不自由だし…
足掛け24時間以上書き込んでようやく終わりが見えてきました。
結局、手元からstretch環境は無くなっただけというｗ
成果物としては、alsamixerのためにteratermのF1～F5がターミナル上で機能するキーマップファイルが出来上がった。が、これも逃げ道があって[TAB]キーでF3～F5の代用は可能という事実…ま、それもF1キーが有効にならないと気が付かないということで。
デフォルトのKEYBOARD.CNFを直接書き換えちゃいましたが、リンクを張り付けておきます。今使ってるのはUSキー配列ですが、多分いまのwindowsなら使えると思います。
0 件のコメント:
コメントを投稿