2015年11月アーカイブ

デバイスドライバとは！Hardware を駆動させるプログラムである。

というのはまぁ常識なんですが、性格には Hardware を駆動させるプログラム、すなわちHWのレジスタを直接操作するコード郡と、Kernel の UpperLayer からデータや制御コードを受け取ることが重要です。というか、UpperLayer からあれこれもらわないと、ドライバだけ存在してもなーんも意味がありません。
オーディオデバイスのドライバーは、UserLand からの音声データを Kernel に中継してもらって、受け取らないといけないわけです。

でだ、ドライバは 「わっちは、オーディオデータ受け取れるですぜ、だんな」 と宣言してオーディオドライバとして動くわけですよ。ドライバの Attach 関連の処理って、config_found() を使うんですが、こいつはまぁ関数ポインタ使いまくりなので、追いかけるのが大変。

ちうわけで、オーディオドライバーの Attach 関連で分かってることをつれずれと。

まず、ドライバがオーディオに Attach する API が audio_attach_mi()

プロトタイプはこんなの

device_t audio_attach_mi(const struct audio_hw_if *, void *, device_t);

構造体 audio_hw_if が特徴ですな。ここから、Attach 処理の実体 audioattach() までの呼び出しがこんな感じ

device_t     audio_attach_mi(const struct audio_hw_if *, void *, device_t);
  device_t   config_found(device_t, void *, cfprint_t);
    device_t config_attach_loc(device_t, cfdata_t, const int *, void *, cfprint_t);
      void   audioattach(device_t, device_t, void *);

先ほどの audio_hw_if は、audioattach() 関数内で hwp = sa->hwif として、hwp 変数に受け渡される。

Attach 処理がうまくいかないときは、この hwp を追いかけるといいようだ。

京都　亀岡の民宿で、オーディオ合宿です。

スピーカが4種類。上に載ってる黒い3wayが私のスピーカーで、トラベリングオーガスト流してみました。

あと、アンプも

そして、もっとも重要なのがこれ！

音がよくなる薬！

裏蓋のネジ7本外すだけで簡単に開いた。この辺は、Lenovoっても Thinkpad というところか。

システム SSD は mSATA 接続されてるんですが、そのすぐ隣にもう一個 mSATA コネクタが付いてました。どうやらドライブ拡張ができるみたいです。

NetBSD Kernel の Source のなかで、Raspberry PI に関連するのはここ。

なお、ここに書いている以外にもファイルはあるんですが、理解できてないものは書いてません。

src/sys/arch/evbarm/rpi

• rpi.h
• rpi2_start.S ・・・・ 起動コード
• rip_machdep.c ・・・・マシン依存コード。デバイスの初期化を呼ぶのはここから

src/sys/arch/arm/broadcom

• bcm2835_bsc.c / bcm2835_bscreg.h  ・・・・ シリアルポートドライバ
• bcm2835_dma.c / bcm2835_dma.h  ・・・・・　DMA　コントロールドライバ
• bcm2835_genfb.c  ・・・・・　フレームバッファドライバ
• bcm2835_gpio.c / bcm2835_gpio_subr.c / bcm2835_gpioreg.h  ・・・・・・ GPIOドライバ　GPIOピンをALTモードにするためのコードもここに入ってる
• bcm2835_obio.c  ・・・・・　ARM Core　と SoC ペリフェラルを結ぶ AMBA AXI バスのドライバ。各ペリフェラルの resigistration コードはここから呼ばれる
• bcm2835_spi.c / bcm2835_spireg.h  ・・・・　SPI /　I2C ドライバ
• bcm2835_vcaudio.c / bcm2835_vcaudioreg.h  ・・・・　HDMI / イヤホン端子出力のオーディオドライバ。残念ながら　I2S はここではない
• bcm2835reg.h  ・・・・・・　SoC としてのドライバ。各ペリフェラルのベースアドレスとかが入ってる

src/sys/external/bsd/vchiq/dist/interface

• *.c  ・・・・・ なんだかよく分からんけど、VCHIQ とかいう仕組み(どうやらバスらしい)に関するコード郡。vcaudio はこのバスに繋がってるらしい

早速、NetBSD-RPI で Volumio 計画を始めます。

まずは開発環境を整えないと話になりません。

NetBSD のいいところは、何と言っても OS 思想に組み込まれたマルチプラットホーム。Raspberry PI Port も当然のようにあります。いや、誰かが作ってくださったからあるので、当然なんかじゃないんですけどね。

なので、この恩恵にあずかるべく、x64 環境で ARM-7 をクロスコンパイルします。

NetBSD の設計思想に従うのであれば、Build.sh を使ってコンパイルするんですが、実は私、これがあまり好きではありません。コンパイルするときに、いちいちオプション引数を大量に渡さないといけないので、面倒なんです・・・・

なもんで、統合 Makefile を使います。

work/
  |
  +---- Makefile
  |
  +---- src
         |
         +--- bin
         |
         +--- sys
         .
         .
         .

こんな感じに Source を展開して、work ディレクトリで make コマンドを実行すれば、クロスコンパイルツールをつかってコンパイルしてくれるという仕組みです。NetBSD は 7-Release
※ src ディレクトリの下に、NetBSD の全 Source を展開するという意味ですよ。

んでまって、その Makefile がこれ

今のところ、これでコンパイルできるのは、

make tools

make sys

のみです。言わずもがな、ビルドツールのコンパイルと、Kernel のコンパイルです。

なお、この Makefile は作業中のものなので、要らないターゲットとか、ゴミがごっそり入ってます。使いこなしたい方は、再利用するなり、消すなり好きにしてください。

んでまって、大切な注意が一つ、コマンドサーチ path に　./ が含まれていると、ビルドツールのコンパイルに失敗します。

/bin/sh /usr/work/NetBSD-RPI/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/mkconfig.sh bconfig.h
c++ -c   -O -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/usr/work/NetBSD-RPI/src/tools/gcc/../../external/gpl3/gcc/dist/gcc -I/usr/work/NetBSD-RPI/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/build -I/usr/work/NetBSD-RPI/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/../include -I/usr/work/NetBSD-RPI/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/../libcpp/include -I/usr/work/NetBSD-RPI/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/../libdecnumber -I/usr/work/NetBSD-RPI/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/work/NetBSD-RPI/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/../libbacktrace   -DNETBSD_TOOLS -DTARGET_SYSTEM_ROOT=0  -DTARGET_SYSTEM_ROOT_RELOCATABLE \
        -o build/genconstants.o /usr/work/NetBSD-RPI/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/genconstants.c
/var/tmp//ccIeCbYA.s: Assembler messages:
/var/tmp//ccIeCbYA.s:6: Error: unrecognized symbol type ""
/var/tmp//ccIeCbYA.s:10: Error: bad instruction `movq (%rdi),%rax'
/var/tmp//ccIeCbYA.s:11: Error: bad instruction `cmpq $0,16(%rax)'
/var/tmp//ccIeCbYA.s:12: Error: bad instruction `jne .L4'
/var/tmp//ccIeCbYA.s:13: Error: bad instruction `subq $8,%rsp'
/var/tmp//ccIeCbYA.s:15: Error: bad instruction `movq 8(%rax),%rdx'
/var/tmp//ccIeCbYA.s:16: Error: bad instruction `movq (%rax),%rsi'
/var/tmp//ccIeCbYA.s:17: Error: bad instruction `movl $.LC0,%edi'
/var/tmp//ccIeCbYA.s:18: Error: bad instruction `movl $0,%eax'
/var/tmp//ccIeCbYA.s:19: Error: bad instruction `call printf'
/var/tmp//ccIeCbYA.s:20: Error: bad instruction `movl $1,%eax'
/var/tmp//ccIeCbYA.s:21: Error: bad instruction `addq $8,%rsp'
/var/tmp//ccIeCbYA.s:23: Error: bad instruction `ret'
/var/tmp//ccIeCbYA.s:25: Error: bad instruction `movl $1,%eax'
/var/tmp//ccIeCbYA.s:26: Error: bad instruction `ret'
＜後略＞

こんなのが出たら、コマンド Path に ./ が含まれてます。

クロス用の gcc をコンパイルしている途中に、Host 用の cc でコンパイルしないといけないのに、クロス用 cc を使ってコンパイルした結果、アセンブラが意味わかんねーよ！とエラーになるみたいですね

Volumio でごそごそやってたのが、そろそろ半年前。

さっぱり進展なし・・・なんですが、それがなんでかといいますと、Linuxだからなんです。私の方針としては Volumio はあくまでオーディオプロジェクトなので、音質改善を図れないと意味がありません。

音質改善のポイントとしては、MPDをいじるか、ALSAをいじるか、サウンドドライバーをいじるかしかないわけです。まぁ、ふつーに考えたらドライバー　＞　ALSA　＞　MPD の順に効果がありそうです。ちうわけで、ドライバーから弄ろうかと思ったんですが、

いやぁ・・・・・Linux の流儀がわからん！！

前回のが、.config をどっかから持ってきて、差し替えて、「いえーい、音質改善したぜー」って言うのがせいぜいだったのはこのせい。

こりゃアカン

ってことで、Raspberry PI と NetBSD で Volumio 相当のことをやってみようと思います。

プロジェクトなんだから、目標を設定せんとイカンですね。

第一目標 ： Raspberry PI の I2S 出力からオーディオ出力を可能にする

第二目標 ： 改良版 Volumio よりいい音（私の主観）を出す

第三目標 ： 手作りアンプの会 関東支部の某E氏に「いい音」と言わせる

なお、絶対に完成する！なんていう自身はありません。

途中で投げ出すかも。なので、過度な期待はしないでください。

できました！！
いい音、鳴ってます

手作りアンプの会でお世話になりっぱなしの、某氏（オンラインに名前出してるんでしたっけ？）設計の無帰還アンプ、発注基板をつかったリリース版です。

今まで、エッチングとかで製作回をやっていたらしい（私は参加してなかった）のですが、とうとうプリント基板化されました。

部品未実装時の基板がこれ。片チャンネルで部品点数おおよそ200、抵抗だけでも68個、トランジスター31個、コンデンサー48個。そして、集積回路は1個だけ、OP-アンプをDCサーボの補助回路に使っているだけという、代物です。

部品乗せた写真がこんな感じ基盤の半田付けだけで15時間くらいかかってます。

そして、アンプというか、オーディオ装置作るときに重要なのが電源回路。メイン基板はもちろん重要ですけど、電源もめっさ大切です。本当は、電源トランスから左右別電源にしたほうがいいのでしょうけど、今回は基板設計者さんから、トランス付きでセットにしてもらえたので、そのまま使いました。コンデンサーとかダイオードブリッジとかだけ自前調達です。

そして、今回は木製シャーシにしてみました。
ただし、まだ完成じゃありません。これからカバーをつける予定です。で、とーぜんカバーが痛材を兼ねます。どうやってのっけるか、思案中・・・・

最後に今回の製作で知ったこと。

FETって、G-S電圧が低いときって完全にカットオフするんですね・・・・・・

「おい！今更なに言ってるんだ？？」と言われそうですけど、トランジスタってB-E電流がちょっとでも流れたら、C-E電流流れるぢゃないですか。だから、G-S間に1V程度かかってりゃ、D-S電流が流れると思ってたんですよ。

このアンプ、最終出力段は上下のコンプリメンタリFETになってて、ある程度のアイドル電流を流さないといけないですね。回路くみ上げて、さぁ、アイドル電流を調整しようかと。G-Sに1Vかかってるから、まぁ微量の電流くらい流れてるだろ？と思って計ったら、あんれぇ？？じぇんじぇん流れてない。

素子壊したか？？と思いつつデータシート見てみたんですね（最初に見ろ）そしたら、G-S電圧2Vくらいから、D-S電流が急激に立ち上がってる。立ち上がる前はグラフ上0A。まぁ、厳密に計れば、数μAくらいは流れてるんでしょうけどね。

アイドル電流調整の仕組みを触って、G-S電圧を1.8Vくらいまで持っていったら、ちゃんと流れました・・・・・

クラウドストレージ、OneDriveとか、ASUS WebStrageとか、Dropboxとかいろいろありますが、私は使いたくありません。だって、あの手のサービスって提供業者が「やーめた」って言ったら終わりなんです。つい最近もOneDriveが容量へらすーとか言い出してすでに使ってる人はどーするんだよ？と思った次第。

ちうわけで、誰かが管理してるサービスなんて信用できねぇ！サーバは自前でもつもんだ。と思っておるわけですが、オンラインストレージにも良いものがあります。ownCloudというパッケージで、商用サービスがありつつ、アプリケーションだけGPLライセンスで公開されているという、最近のパターン。

といわけで、早速FreeBSD上に構築してみます。インストールしたportは次の通り。FreeBSD 10.2をインストールして、2015/11/7のportsnapを展開してます。

• www/owncloud
• www/mod_php56
• database/postgresql93-server

httpd.confの設定とか、PostgreSQLの初期設定とかは適宜。

で、サーバそのものの構築がおわったら、次はProxyの設定。

ownCloudサーバ自体はプライベートアドレスのセグメントに置いて、The InternetにつながるWebサーバにProxyを設定することでサービスを実現します。セキュリティの都合もありますが、新機能のサーバを立てるときに、なにも考えず新サーバをたてて、ProxyでURLみて振り分けてしまえば、既存の機能に影響をあたえることなく、新機能が追加できるので、こんな方法を使ってます。

Proxyマシンのhttp.configにこんなのを追加

ProxyPass /owncloud http://xxx.xxx.xxx/owncloud

ProxyPassReverse /owncloud http://xxx.xxx.xxx/owncloud

つぎに、Proxyで通ってきてもいいよ、とownCloudを設定する必要があります。/usr/local/www/owncloud/config/config.phpファイルを開いて、

  'trusted_domains' =>
  array (
    0 => 'xxx.xxx.xxx',
    1 => 'yyy.yyy.yyy',
  ),

こんな風に書き換えます。xxx.xxx.xxxがownCloudサーバのプライベートアドレス、yyy.yyy.yyyがProxyサーバのグローバルアドレス。これをしておかないと、Proxy経由で接続したときにエラー画面に飛ばされて、利用開始ができません。

ここまでがサーバの構築の話なんですが、とーぜんながらサーバだけ構築してもなーんの意味もありません。

ちうわけで、クライアントを設定します。

まず、Windowsクライアント。ここからインストーラをダウンロードし、インストールします。

これがクライアント画面。Defaultでインストールすると、C:\Users\USERNAME\ownCloud ディレクトリを作って、ここを同期対象に設定します。

他のディレクトリを同期したかったら「Add Folder Sync Connection」ボタンを押して設定してあげればいい・・・・んですが、なにも考えずにインストールすると、このボタンは無効化されます。DefaultのownCloudディレクトリを対象にすると、このボタンが無効化されちゃうんです。なので、一度同期設定を削除して、改めて Add Folder Sync Connectionしてやりましょう。

同期対象はいろいろあるでしょうけど、ひとつお勧めはこれ

C:\Users\USERNAME\AppData\Roamingディレクトリと、C:\Users\USERNAME\Saved Gamesディレクトリをターゲットにしてます。エロゲのセーブデータの同期ですね。ただし、Roaming ディレクトリはゲームのセーブデータ以外にもいろんなデータが入るので、適宜はずすものは外す必要があります。とくに、Janetterとか入れてると、んGB単位のでっかいファイルを同期しようとするので、注意しましょう。

次に、Androidクライアントの話。

Andoriodのクライアントもあります。Playストアに入ってます。これ、なーんでか有料ソフトです。ちうても、99円ですが。なんでわざわざ有料にしてるんだろ・・・？

当然、ダウンロード／アップロード両方できます。ストレージに入ってるデータが、画像データだったら ownCloud Client の画像ビューアが立ち上がります。音声ファイルだったら、ownCloud Client のプレイヤーが立ち上がります。それ以外だったら、どのアプリケーションで開く？って聞いてきます。

ただ、この Client が残念なのは、同期ディレクトリを設定できないこと。

たとえば、Twitcle で Twitter に流れてるえちぃイラストを保存するっていうのは、誰しもやることだと思うのですが、その画像ファイルは、/sdcard/Download というディレクトリに保存されます。なので、ここを同期対象にできれば、Twitcle でダウンロードさえすれば、自動的にオンラインストレージに保存されるわけですが、これができません。

仕方ないので、

1. Twitcle でえちぃイラストをダウンロード
2. 「ギャラリー」アプリケーションでイラストを選択
3. 「共有」から ownCloud を選択してアップロードディレクトリを選択

という手順が必要になります。

しかも、「共有」からアップロードディレクトリを選択するためには、ownCloud Client アプリケーションでアップロードしたいディレクトリの情報をキャッシュさせておかないと選択できないという。ちょっと残念なつくり

まぁ、欠点を補って十分な便利さがあるんでいいんですけどね