コグノスケ

ALSAのミキサーとregmapその1 - ミキサーとkcontrol

目次: ALSA

メモ代わりの超マニアックな話です。なぜALSAのドライバ、特にミキサーがregmapを使うのかを調べました。

ALSAのドライバでミュートのON/OFFとか、ボリューム上げ下げの機能を実装するときに、kcontrolというフレームワークを使います。

ボリュームはさらにもう一つ仕組みがあって面倒なので、ミュートON/OFFスイッチを例にします。下記はTexsas InstrumentsのTAS5711というDACのドライバです。

//from linux-4.4/sound/soc/codecs/tas571x.c

static const struct snd_kcontrol_new tas5711_controls[] = {
...
        SOC_DOUBLE("Speaker Switch",
                   TAS571X_SOFT_MUTE_REG,
                   TAS571X_SOFT_MUTE_CH1_SHIFT, TAS571X_SOFT_MUTE_CH2_SHIFT,
                   1, 1),
};

引数の意味はスイッチの名前（Speaker Switch）、レジスタのアドレス、Lチャネルを制御するときのシフト数、Rチャネルを制御するときのシフト数、最大値、反転するかどか、みたいです。

「反転するかどうか」を何に使っているかというと、通常ON = max値, OFF = min値という意味ですが、ON = min値, OFF = max値にするようです。TI TAS5711仕様書のSOFT MUTE REGISTER (0x06) を見た感じ、Muteするときは1設定しろとありますので、多分合っていると思います。間違ってたらごめんよ。

もちろんこれだけではダメで、struct snd_soc_codec_driverのcontrolsにポインタを代入し、snd_soc_register_codec() に渡す必要があります。

どうもtas571x.cのドライバはTAS5711とTAS5717という2つのDACに対応するため、渡し方がちょっと変わってるので、TAS5086用のドライバを見ます。

//from linux-4.4/sound/soc/codecs/tas5086.c

static const struct snd_kcontrol_new tas5086_controls[] = {
        SOC_SINGLE_TLV("Master Playback Volume", TAS5086_MASTER_VOL,
...

static struct snd_soc_codec_driver soc_codec_dev_tas5086 = {
        .probe                  = tas5086_probe,
        .remove                 = tas5086_remove,
        .suspend                = tas5086_soc_suspend,
        .resume                 = tas5086_soc_resume,
        .controls               = tas5086_controls,    //★snd_kcontrol_new配列のポインタをここに渡している★
        .num_controls           = ARRAY_SIZE(tas5086_controls),
        .dapm_widgets           = tas5086_dapm_widgets,
        .num_dapm_widgets       = ARRAY_SIZE(tas5086_dapm_widgets),
        .dapm_routes            = tas5086_dapm_routes,
        .num_dapm_routes        = ARRAY_SIZE(tas5086_dapm_routes),
};

static int tas5086_i2c_probe(struct i2c_client *i2c,
                             const struct i2c_device_id *id)
{
...
        if (ret == 0)
                ret = snd_soc_register_codec(&i2c->dev, &soc_codec_dev_tas5086,    //★snd_soc_codec_driverのポインタをここに渡している★
                                             &tas5086_dai, 1);

        return ret;
}

こんな感じです。本当に言いたかったことはregmapですけど、出てこないうちに終わってしまいました。また次回にします。

最速のyes

目次: ベンチマーク

How is GNU `yes` so fast?を読んで。このサイトを Twitterで知って面白かったので、やってみました。

記事の最後にあるプログラム（iteration 4）のバッファサイズを8KBから16KBに変更するとGNU yesより速くなるようです。

家のLinuxマシンでやってみたらyesというかcoreutilsのバージョンによって全然速さが違うことがわかりました。

CPU                 : GNU yes 8.23 : GNU yes 8.26 : 自家製yes（バッファ16KB）
AMD A10 7800        : 123MiB/s     : 2.8GiB/s     : 3.2GiB/s
Intel Pentium J4205 : 40MiB/s      : 1.9GiB/s     : 2GiB/s

何も変わっていないように見えるyesも実は速度が進化したんですね…。

メモ: 技術系の話はFacebookから転記しておくことにした。

実はハイレゾも再生できる、我が家のアンプ

なぜハイレゾは「バカげている」のかを読んで。

記事の内容についてはさておいて、リンクされてるWAVファイル再生してみたところ、歪みなどは全く何も聞こえませんでした。ONKYO SE-U33GXV2はお値段の割にとても良いアンプだと思います。

以前22kHz Sin波を再生させて、オシロで見た（2014年11月25日の日記参照）ときも、鳴り始めが美しいSinc関数になっていて、波形の打ち切りなどもありませんでした。基本に忠実＆作りが良いのでしょう。

何も考えないで適当に買ったんですけど、買って良かった一品でした。

私の耳とハイレゾ

私にはハイレゾは意味がありませんね。聞こえないし、差もわかりません。

そもそもDAT（fs = 48kHz）とCD（44.1kHz）の差だってわかりませんし、もっといえばfs = 32kHzつまり16kHz以上の音を打ち切っても差がわかりません。

まあSin波だけデカい音量で鳴らせば16.5kHzくらいまでは聞こえますが、17kHz以降はもう何しても全然聞こえません。どう考えてもCD音質より上は要らないです……。

私にはハイレゾは意味ない（＝わからない）というだけであって、ハイレゾ音源なんか買うな！とか、売るな！とか、そんなことは微塵も思っていません。

趣味の世界なんですから、楽しくやるのが一番です。差がわかろうがわかるまいが、死にゃあしねえし、外野の声なんて、気にしないで楽しむのが一番です。

メモ: 技術系の話はFacebookから転記しておくことにした。

Wizardry（囚われし亡霊の街）敵が強すぎる

目次: ゲーム

昔買って放置していた「Wizardry囚われし亡霊の街」を進めているのですが、シナリオ1終盤（アウダークルク迷宮B6F）辺りで、進めなくなりました。敵が強すぎます。

自キャラHP 600に対し、同レベルの敵が2000ダメージ以上ぶち込んでくるので必ず一撃で死にます。レベル上げれば何とかなる系なのかなあ？？

シナリオ3まで一気に買ってしまって後悔しています。こんなマゾいバランスだとは思いませんでした。せめてシナリオ1はクリアしようと思いますが、シナリオ2, 3は多分やらないです。

FacebookのコメントでB6F辺りから運ゲーらしいことを教えてもらいました。うーん、そういうもんなのか。

メモ: 技術系の話はFacebookから転記しておくことにした。

パーティー編成

今のパーティー編成は、侍x 2と野伏と司祭x 3という大変偏った構成にしています。

何でかというと、侍は武器が強いことと、ノーリスクで敵1グループを一度に殴れる強力な固有スキルを持っているためです。前作の「囚われし魂の迷宮」では大変強かったので、今作も強いだろうと期待して侍を入れました。

野伏は盗賊の上位互換です。盗賊の技能＋僧侶系の魔法の一部を覚えます。Wizardryは扉や宝箱に鍵だの罠だのが掛かっていて、いきなり開けると罠に殺されるので、解除するために盗賊の技能が必須です。

司祭は僧侶系、魔法使い系の魔法を両方覚えます。Wizardryはダンジョンで拾ったアイテムが全て「不明な何か」になるので、鑑定スキルを使わないと何を拾ったかすらわかりません。司祭は1人は居た方が良いです。

司祭の人数がやたら多いの魔法の使用回数が簡単に尽きないように人数でカバーするためです。Wizardryは魔法が9レベルに分類されていて、各レベル最大でも9回しか魔法が使えません（使用回数は作品に依って違うことがある）。どんなにキャラクターレベルが高かろうが9回同じ魔法を使ったら同じレベルの魔法は使えません。特に魔法使い系Lv.8はワープ系の魔法がありまして、ここの使用回数が尽きてしまうと、ダンジョンから帰るのが大変面倒になります。

ダンジョンには魔力を3減らしてくるクソみたいな敵も居て、魔法を使わずとも使用回数が0になることがありますが、さすがに司祭が3人も居れば全員の魔法が尽きることはありません。その前に殴られて死ぬ方が多いです……。

強すぎる侍、弱すぎる魔法

パーティー編成の思惑は大体当たっていたのですが、手痛い計算違いは攻撃魔法が弱すぎて後衛が置物になってしまったことです。

侍は武器さえあればメチャクチャ強いです。特に中盤の岩融という槍がバカみたいに強く1撃で1,000以上のダメージを与えられます。ほとんどの敵が一撃で沈みます。

また今作は課金アイテムとして虎徹など、シナリオ後半で出てくる刀を序盤から使えます。試しに買ってみたところ、攻撃力不足で苦戦していた序盤の敵が紙切れのごとく蹴散らせました。武器の差が異常すぎます。

司祭は計算違いでした。魔法で強力な攻撃が出来ると思っていたのですが、全然ダメでした。僧侶系最強のSmiteや、魔法使い系最強のNAL Burstですら200〜300ダメージと弱く、3人がかりで連発してやっと効き目があるかどうかです。弱すぎます……。

異常な強さの敵

このゲームで一番やる気が削がれるポイントは「敵の異常な強さ」です。敵が4桁以上のダメージを与えてくるので、前衛、後衛関係無く即死します。それでも防ぐ手立てがあるならまだ良いんですけど、防具による防御力は100行けば良い方で気休めにもなりません。防御系の魔法もほとんどありません。

侍辺りが先攻で攻撃できれば倒せるんですが、敵の方が圧倒的に速くて先攻が取れません。完全に詰んでます。どうしたら良いんだ。

クソゲーにノミネート

雑魚に全く勝てないので、私は数歩歩いてセーブ、敵にぶち殺されたらリセット＆ロード、を繰り返しながら進めています。はっきり言って、全く面白くないです。しかもこのゲームは動きが全体的に遅いので、さらにイライラ度が上がります。

一体、他の人はどうやってクリアしているのか調べていたら、今作がクソゲー・オブ・ザ・イヤーにノミネートされているのを見つけてしまいました。あー、他の人も同じこと思ってるのね……。

前作はモッサリしてる以外は、そこそこ面白かったんだけどなあ？今作はちょっとクリアする気が起きないです。

USB 3.0

先日（2017年6月2日の日記参照）の続きです。USB 3.0機器のそばにワイヤレスマウスやワイヤレスキーボードのレシーバーを設置すると、動かなくなってしまう現象についてです。

まず、本当にUSB 3.0のせいなのか気になります。

CQ出版「USB 3.0設計のすべて」を良くわからんながらもパラパラ眺めているのですが、USB 3.0はPCI ExpressのPHYを使い回せるという記述がやたら出てきます。

なるほど、高速SerDes設計は難しいのでUSB 3.0用に新たに起こすより、PCI ExpressのPHYを使い回せる方が半導体ベンダも楽だし、結果的に安くなるしハッピーですよね。

5Gbpsというバカっ速な信号の取り回しは大変ですが、物理層、コネクタ、ボード設計にPCI Expressのノウハウが使い回せることも恩恵だそうです。これも結果的に値段に反映されてハッピーですね。

だからUSB 3.0の物理層とPCI Expressの物理層の間で、2ペア作動信号による全二重通信、8b/10bエンコード、そして信号速度5Gbpsなど共通点が多いのは、偶然では無いのです。

5Gbpsの信号速度と2.4GHz無線の関係

USB 3.0の信号速度は5Gbpsです。ということはクロックは5GHzのはずで、一番強烈なノイズは5GHz付近じゃないかと思ったのですが、何故2.5GHzなのでしょうか？

まず確実に言えるのは、USB 3.0にクロック信号だけを伝える配線は存在しないことです。PCI ExpressやUSB 3.0の8b/10bエンコードは信号とクロックを一緒に送る、埋め込みクロックと呼ばれる信号の送り方をするため、5GHzで単純に振動する信号はありません。

USB 3.0は5Gbpsと名乗るからには、送信側、受信側ともに信号を5G回/sで見ている、つまり1bitの間隔が0.2nsになっているはずです。もし0.2ns間隔で1, 0を交互に繰り返すような信号なら2.5GHzの正弦波に近い信号になるため、2.5GHz付近にノイズが発生するはずです。

しかし8b/10bの信号表を見ていると1, 0が交互に出るパターンも存在しますが、1, 1, 0, 0のように同じ値が2回以上続いてから反転するパターンの方が多いように見えます。

少ないとは言え8b/10bエンコーディングで1, 0のパターンが生成される以上、USB 3.0が2.5GHz帯にノイズを出すことは間違いないと考えられますが、この考え方であってるんでしょうか？何だかスッキリしません……。

規格でのノイズ対策は？

本に依れば、コネクタやレセプタクルに厳しく品質を求めており、スペクトル拡散クロック（SSC）が必須でEMI対策を頑張っているようにも見えます。

SSCで特定の周波数にピークが来るようなノイズは防げるけど、如何なSSCと言えども満遍なくノイズが発生するのは避けられません。また、ワイヤレスマウスやキーボードの出力がそれほど強いとは考えにくいので、無線がノイズに負けやすいのかもしれません。

DTIの実力

目次: プロバイダ

先日（2017年5月29日の日記参照）の続きです。

DTIからPPP接続のIDやパスワードが送られてきましたので、早速、接続先を切り替えて通信速度を測ってみました。

比較しやすいように、先週に計測したWAKWAKの通信速度と重ねてグラフを作成しました。計測した日が異なるので厳密な比較ではありません。あと横軸の時間は大体同じに揃えましたが、計測の都合上10分くらいズレてます。

日曜の速度推移、WAKWAK v.s. DTI

DTIは速いです。けっこう速度が揺れていて、今後、人が増えたらWAKWAKと同じ結末になるのでは……という不穏な気配もありますが、今のところ、日中〜夕方の速度は圧倒的です。10倍以上速いです。

これならAmazonの漫画も数分でダウンロードできます。DTIにして良かったです。