目次: ARM
去年だったか、ROCKPro64のHDMI音声出力を有効化するパッチをlinux-nextに送ろうとしたことがあります。当時のレビューコメントでSPDIFとHDMIの音声ビットストリームパススルー出力(※1)は動くか?と聞かれたものの、テスト環境がなかったため、わからないまま挫折してしまいました。
今回、再チャレンジにあたり、テスト用にSPDIFとHDMIの音声ビットストリームをデコードできる機械を探しました。これがどうして、お手頃価格の良い商品が見当たらないです。
AmazonではSPDIFのみ対応の商品がありました。メーカーが怪しい、色んなバージョンが色んな店から売られている、そもそも動くの??など不安は募りますが、ダメ元で購入しました。
大手メーカー製を探すと、ホームシアター用ヘッドホンシステム3〜4万円、もしくはAVプリアンプ10万円over!のような大げさな商品しかありません。
音声ビットストリームパススルー出力が、いかに高コスト&需要がないか良くわかりました。普通の人は音声信号がLPCMかパススルーかなど細かいことは気にしませんから、当然の成り行きでしょうね。
(※1)音声信号としてLPCMではなく、Dolby Digital(AC-3)やDTSをデコードせず圧縮音声のままSPDIFやHDMIに出力する方式のことです。デコードは受信機器側で行います。
SPDIFパススルーのテスト用に、中国製と思われる謎の機械(型番なし、筐体にはHD AUDIO RUSHと書いてある)を購入しました。Amazonで4,000円くらいです。安い!事前の不安をよそに音は正常に鳴っています。素晴らしいです。
しかし本体にコーデックのインジケータがなく、LPCMか音声ビットストリームか全く判別がつきません。テスト用の機材としてはイマイチでした。10分に1回くらいSPDIF信号のPLLロックが外れた(?)と思われる、数秒レベルの音切れが発生します。ROCKPro64の出す信号が悪いのか、HD AUDIO RUSHが悪いのか、切り分けできず真因は不明です。
SPDIFだけだとLPCM 96kHz 16bit 2ch(3.072Mbps)のような、SPDIF(Max 1.5Mbps)の帯域を超える音声信号はテストできません。無理やり流すと酔っ払いが演奏してるみたいな変な音になります。HD AUDIO RUSHくん以外にHDMI用のテスト機材が必要です。
HDMIのテストならテレビ(Panasonic TH-L37DT3)で確認できるだろ、と思っていたら、HDMI音声入力はLPCM 2chのみの対応でした。LPCMは2ch以外にも5.1ch出力(※2)がありますがテストできません。ダメだこれ。
覚悟を決めてサラウンドヘッドフォンシステムSONY MDR-HW700DSを注文しました。37,000円くらいします、高い!まだ家に届いていませんが、来週辺りかな、人生初のSPDIF/HDMI音声ビットストリームパススルー対応機器が手に入ります。
(※2)身近な例でいうとNintendo Switchのサラウンドモードが、LPCM 5.1ch出力を使います。試しにSwitchをサラウンドモードにすると、テレビから全く音が出ませんでした。がっかり。
 この記事にコメントする
 この記事にコメントする
目次: ARM
今更ですが、メモしていなかった気がするので、ROCKPro64(Rockchip RK3399搭載)でHDMI Audioを有効にする方法です。
方法は簡単でLinuxのCONFIG_DRM_DW_HDMI_I2S_AUDIOと、CONFIG_GPIO_SYSCONを有効にすれば良いです。8/7時点のlinux-nextのツリーでは、make defconfigすると、GPIO_SYSCONはnで、ビルド対象外になっています。手動で下記の設定を有効にする必要があります。
  Device Drivers  --->
    -*- GPIO Support  --->
      Memory mapped GPIO drivers  --->
        [*] GPIO based on SYSCON
    Graphics support  --->
      Display Interface Bridges  --->
        [*] Synopsys Designware I2S Audio interface
    [*] Sound card support  --->
      [*]   Advanced Linux Sound Architecture  --->
        [*]   ALSA for SoC audio support  --->
          CODEC drivers  --->
            [*] Everest Semi ES8316 CODEC
CONFIG_SND_SOC_ES8316はアナログオーディオを使いたい場合に有効にしてください。
 この記事にコメントする
 この記事にコメントする
目次: ARM
以前(2020年8月1日の日記参照)購入したSONY MDR-HW700DSが届きました。早速ROCKPro64でHDMIのビットストリームパススルーをテストしたいと思います。
ビットストリームパススルーは、SPDIFやHDMIに対して、圧縮音声データ(Dolby AC-3, DTS, MPEG2 AACなど)をデコードせず、そのまま送信する方式です。この方式の最大の利点としては、サラウンド音声が楽しめる点が挙げられます。
SPDIFは帯域が狭く、デコード後のサラウンド音声(LPCM 5.1ch)を送れません。しかしSPDIF上を圧縮音声のまま送信し、受信機であるホームシアターシステム側で音声をデコードすることで、SPDIFでもサラウンド音声が楽しめます。
HDMIの場合は利点がないかと言うとそうでもありません。LPCM 5.1chを送出できない機器もありますし、ホームシアターシステムに適したデコードやミキシングができる可能性もあります。
SPDIF/HDMIパススルーに対応したプレイヤーはいくつかあるようですが、今回はmpvを使用します。
GitHubにあるALSAのコンフィグファイル(GitHubへのリンク)を ~/.asoundrcなどに追記します。再生時にaudio-spdifオプションで出力フォーマットを指定します。再生するファイルの音声フォーマットと合っていれば、パススルーで出力されます。
$ mpv --no-video a.ac3 --audio-spdif=ac3 --audio-device="alsa/HDMI.pcm.hdmi.0:0" Playing: a.ac3 [ffmpeg/demuxer] ac3: Estimating duration from bitrate, this may be inaccurate (+) Audio --aid=1 (ac3 6ch 48000Hz) AO: [alsa] 48000Hz stereo 2ch spdif-ac3 ★AC3になっている A: 00:00:02 / 00:05:36 (0%)
SONY MDR-HW700DSのステータス画面は本体のインジケーターではなくHDMIの画像データにオーバーレイするタイプなので、HDMIディスプレイの写真を取りました。狙い通りにAC-3が再生されている様子がわかります。
オプションを間違えたり、オーディオデバイス番号を間違えてもエラーにはならず、再生が開始されますが、パススルーではなくデコードされLPCMで再生が開始されます。
$ mpv --no-video a.ac3 --audio-spdif=ac3 --audio-device="alsa/hw:0" ★間違えてhw:0にした Playing: a.ac3 [ffmpeg/demuxer] ac3: Estimating duration from bitrate, this may be inaccurate (+) Audio --aid=1 (ac3 6ch 48000Hz) ALSA lib conf.c:4898:(parse_args) Unknown parameter AES0 ALSA lib conf.c:5031:(snd_config_expand) Parse arguments error: No such file or directory ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM hw:0,AES0=6,AES1=130,AES2=0,AES3=2 [ao/alsa] Playback open error: No such file or directory [ao] Failed to initialize audio driver 'alsa' [ao] This audio driver/device was forced with the --audio-device option. [ao] Try unsetting it. AO: [alsa] 48000Hz stereo 2ch s32 ★LPCMになっている A: 00:00:02 / 00:05:36 (0%)
その他の注意点として、受信機側がパススルー出力で送った圧縮音声に対応していない場合、LPCMだと思って再生してしまい、バリバリバリ!!という凄まじい音量のノイズが再生されることがあります。お試しの際は、音量を小さくしてからテストしてください。
 この記事にコメントする
 この記事にコメントする
Twitterで「これ便利」と紹介されているのを見て知りました(製品紹介へのリンク)。エアコンハンガーというそうです。見た瞬間から「うわー!やめてくれー…エアコンは物干しじゃない」という感想しか浮かびません。
エアコン据付板の耐荷重はマチマチで、耐荷重ギリギリの可能性もあります。ハンガーの耐荷重(5kg)を追加で吊って、エアコン室内機が頭の上に落ちてきたら大ケガします(室内機の重さは10〜15kg)。
パナソニックのエアコン説明書にある山盛りの注意書きを見ましたが「エアコンにモノを吊り下げると、落下しケガする」とは書いていませんでした。家電のユーザーはメーカー想定を超える壊し方をすることは、一応知ってましたが、実例を目の当たりにしたのは初めてです。全く嬉しくないですね。
エアコンハンガーの利用で、事故やケガにあっている人がいないことを祈ります……。 ちなみに、エアコンハンガーのメーカー注意書きに、
「下地がしっかりしていない壁に取り付けられているエアコンには使用しないでください。エアコンが落下する恐れがあります。(例: 下地にベニア板の無い石膏ボードなど)」
と言い訳が書いてありますが、一般人が壁の素材と下地を知るわけないでしょう?本気で言ってるのか??
メモ: 技術系?の話はFacebookから転記しておくことにした。
 この記事にコメントする
 この記事にコメントする
Wikipediaに寄付しました。といっても5,000円ですけども。
Wikipediaの運営元(Wikimedia Foundation, Inc.)は広告なしでWikipediaのような巨大システムを維持していて、さすがだと思いますけど、寄付催促メールのしつこさはちょっと嫌ですね……。
メモ: 技術系?の話はFacebookから転記しておくことにした。
 この記事にコメントする
 この記事にコメントする
目次: 車
車検証と検査証票(フロントガラスに貼るステッカー)が届きました。
いつもならディーラーさんに1週間くらい預けるので、車検証もそのときに付いてきます。今回は奥さんの通院の送り迎えに車が必要で、スバルのディーラーさんに無理を言って土日月の3日で車検を終わらせてもらいました。
車検の検査自体は終わっても、車検証の発行が間に合わなかったので、後から郵送されてきた、ってことです。
リアのロアアームブッシュが破損していたので、交換になった程度で、他は特に何もありませんでした。部品の在庫があって良かったです。
 この記事にコメントする
 この記事にコメントする
マクドナルドが各国で味付けが違うのは有名ですが、エナジードリンクにもお国柄があってUSA版のMonster Energyはタウリンあり、日本版はタウリンなしの製品が販売されています。これはRed Bullも同様です。ただしエナジードリンクの場合、味付けの問題ではなく法律の問題です。
日本では、タウリンを入れると医薬部外品になり、製造業者+販売業者の厚労省の許可、商品ごとに承認が必要になります。Monster Energy製造、販売元のアサヒ飲料は清涼飲料水製造メーカーなので、医薬部外品製造の設備は持っていないでしょう。たぶん。
実はヒトはタウリンを外部から摂取しなくても、体内で生合成できますから、生合成の原料となる物質を入れれば良いじゃない?と思うかもしれませんが、そんな甘くありません。厚生労働省の告示(リンク)(※)を見るとわかる通り、タウリンの主要な合成経路「L-メチオニン → L-システイン → タウリン」のいずれも医薬部外品扱いで清涼飲料水には添加できません。
L-メチオニンは必須アミノ酸なので生合成不可能、すなわち他の成分をいくら入れても代用になりません。必須アミノ酸は全て医薬部外品として指定されている辺り、良くできた法律です。
薬事法の目的「保健衛生の向上」を見る限り、必須アミノ酸を規制する意味ある……?という気になりますけど、一方で「医薬品、医療機器及び再生医療等製品の研究開発の促進」という目的もあります。苦労して薬効成分を見つけた製薬会社、高価な製造設備を入れているメーカーの権益を保護してあげるから、これからも医療品の研究開発を頑張ってくれたまえ〜!という法律なんですね。なるほどねえ。
(※)厚生省告示第百九十四号 - 都道府県知事の承認に係る医薬部外品という文書名です。
 この記事にコメントする
 この記事にコメントする
SpO2(血中酸素飽和度)を測りながらCPAPを付けて寝たところ、途中で寝苦しくて起きてしまい、CPAPを外して二度寝しました。このときのSpO2の変化がなかなか面白いです。
CPAP外すとSpO2は明らかに悪化(2枚目)するかと思えば、CPAPない方がマシ(3枚目)な時間もあります。CPAPなしで寝た場合も何度か測っていますが、寝た直後はSpO2が悪化しますが、しばらく経つと悪化しなくなることが多いです。
睡眠のサイクルとか、寝ている姿勢とか、何かしら呼吸が止まる原因があるはずなんですが、寝ている自分には全くわからないし、突き止めるのが難しいですね……。
メモ: 技術系?の話はFacebookから転記しておくことにした。
 この記事にコメントする
 この記事にコメントする
目次: PC
先日(2020年8月3日の日記参照)購入したサラウンドヘッドフォンシステムSONY MDR-HW700DSですが、このような仕様みたいです。
今日の朝、何かの拍子に電源OFFになったらしく、ディスプレイ側に何も映らず真っ黒になりました。最初見たとき、えええ!?もう壊れた?早すぎない??と勘違いして、かなり焦りました。
ダイニングテーブル(普段の作業机がこれしかない)にあまり機械類を置けないので、SONY MDR-HW700DS本体の上に、USB-DACのONKYO SE-U33GXVIIを乗せて使っています。すると5秒に1回くらい、USB-DACの出力にジー…ビー…というノイズが乗ります。ワイヤレスヘッドフォンを探す電波を拾うのでしょうか?
USB-DACのボリュームをいじってもノイズの大きさが変わらないので、アナログ回路で電波拾ってるんですかね?オシロスコープでノイズを測ろうと思いましたが、オシロの測定限界以下らしく測れませんでした。無音でも何も見えません。
オシロで見えない程度のノイズゆえ、音量は極めて小さいです。しかし、私には聞こえる程度の音量はあるので、気が散って仕方ありません。機器を離して置こうにも、場所がないです。困りました。
実はSONY MDR-HW700DSはワイヤレスヘッドフォンとの通信に使う帯域を2.4GHz帯と5GHz帯から選択可能です。ダメ元で切り替えてみたところ、2.4GHz帯にするとビー…というノイズが乗り、5GHz帯だとノイズが乗りませんでした。うおー!やった!これで回避できます。
2.4GHz, 5GHz自動選択機能を付けてくれたSONYの開発者には申し訳ないですが、5GHz固定で使うことにします……。
 この記事にコメントする
 この記事にコメントする
目次: ゲーム
お盆休みの間、行くところも特にないのでThe Hunter: Call of the Wildばかりやっていました。気づいたらプレイ時間が100時間を超えていたので、そろそろ感想くらい書いても良かろうってことで書いてみます。
The Hunterはゲームというより「リアル指向」のスポーツハンティングシミュレータです。とても良くできていると思います。ただですね、最初に言っておきますが、私は「リアル指向」が強すぎるゲームは嫌いです。ゲームとして全く面白くないです……。
気に入ったところ
気に入らないところ
上に挙げた、良い点も悪い点も全て「リアル指向」であることに端を発しています。リアル指向である点が気に入らなければ、ほぼ全てが気に入らないと思います。逆に「リアル指向」が好きな人には最高の作品だと思います。
(※)私のノートPCに搭載されている、Radeon RX 550では歯が立たないです。画質設定を全て最低に落としたうえで、ウインドウモードにして、FullHDの1/4くらいのサイズにしないとまともに動きません。
The Hunter: COTWでは、獲物を仕留め回収する際に点数が付きます。今はAnimal Scoring 2.0という基準だそうです。大まかには、下記を守ると点が高くなります。
最初の「適切な弾丸か?」について捕捉すると、鳥やウサギ、キツネのような小物を、ヘラジカ用の大口径ライフルの弾丸でぶっ飛ばすと点が下がります。獲物と弾丸にはクラス分けがされているので、一致させればOKです。
真ん中の2つについては、致命傷を与えなければ何度も撃つ羽目になるので、たいていは一緒に達成するはずです。
最後の「トロフィー部位は無事か?」については、獲物をはく製にして飾ることが狩りの1つの目的なので、はく製にする部分に穴が開くような撃ち方(=ヘッドショットする)をすると点が下がります。
リアル指向のThe Hunterにおいて、極めて不自然なファンタジーシステムです。
獲物を仕留めた場所に、マップ上で見ると紫色の血飛沫のようなマークがつき、その付近には再び動物が寄りつきにくくなります。時間経過では消えず、他の場所で獲物を仕留めると段々古い狩猟圧から消えるようです。
同じニードゾーンでずっと待ち伏せ狩りすることを阻止したかったのだと思いますが、かなり変なシステムです。全然リアルじゃないでしょう。私の中ではこのシステムがつまんなさに拍車をかけています……。
The Hunterはスコアシステムを考慮して、急所を狙いやすく、弱い弾丸でも威力が保てる至近距離に近づくべきです。が、50mくらいまで近寄ろうとすると、何かと最悪なことが多くて、本当にイライラします。
気づかれないように近づく移動方法として匍匐前進があります。しかし匍匐前進は、速度が遅く時間ばかり掛かってイライラします。いかに慎重に近づいても獲物に逃げられることがあってこれまたイライラします。匍匐前進だと藪で獲物が見えず近づいても撃てないことが多くて、さらにイライラ度が高まります。
真面目に接近しようとするほど、イライラして正直やってられませんので、邪道ハンターのススメ「走り回って、気づかれないほど遠くから、大口径ライフルでズドン」を紹介します。
もしニードゾーンが使えそうなら、
最重要ポイントは、動物への接近に時間を掛けないことです。手早く次にチャレンジできてダルさが激減しますし、動物に逃げられても惜しくありません。The Hunterは動物との遭遇率がかなり低いので、時間をかけて逃げられたときのガッカリ感が半端じゃないです。
次に重要なのは距離を開けることと、高威力のライフルです。距離を100mくらい空ければ、風向きを無視しても、動物が逃げる確率は低いです。大口径ライフルならば急所を外しても即死する確率が高まります。これらの合わせ技により、ハント成功率がかなり上がりました。
とにかく「走り回って、気づかれないほど遠くから、大口径ライフルでズドン」で、お気軽な快適ハンティングを楽しみましょう。
(※2)ニードゾーン=動物の食事、給水、休憩場所のことです。このゲームでは特定の時間帯に、特定の動物がニードゾーンに集まってくるようにできています。かなり強い引き寄せ力をもっているため、待ち伏せ狩りの場所として最適です。
狩猟基準は無視を推奨します。点を上げるには弱い弾1発で仕留める必要があり、そのためには近づく必要があります。近づけば逃げられる可能性が高まります。時間かかってイライラするだけです。健康に良くありません。別に0点だろうが10点だろうが、どうでも良いです。それよりもハントしたいだろ?なあ?
シナリオも無視を推奨します。真面目に追いかけると、シナリオの攻略対象の動物が見つからずイライラするだけで、全く面白くないです。それよりもあらゆる場所で目に付いた動物を乱獲すれば、いくつかは勝手に終わります。暇で仕方なくて、シナリオが気になる!くらいまで、無視して良いと思います。
 この記事にコメントする
 この記事にコメントする
目次: Android
久しぶりにAndroidが動作するボードを購入したので、メモリの使い方を見てみました。開発用ボードはsuが使えるので、情報が何でも取れて楽で良いですね。
最初はKhadas VIM2 Basicというボードです(Linux 3.14.29 aarch64, Android 7.1.2ベース)。Amlogic S912というSoCです。RAMは2GBです。RAMが3GBのProというボードもあります。
MemTotal: 1746388 kB MemFree: 457292 kB MemAvailable: 1170284 kB Buffers: 7384 kB Cached: 676612 kB SwapCached: 0 kB Active: 380856 kB Inactive: 585248 kB Active(anon): 282472 kB Inactive(anon): 612 kB Active(file): 98384 kB Inactive(file): 584636 kB Unevictable: 252 kB Mlocked: 252 kB SwapTotal: 511996 kB SwapFree: 511996 kB Dirty: 76 kB Writeback: 0 kB AnonPages: 282492 kB Mapped: 264172 kB Shmem: 976 kB Slab: 150844 kB SReclaimable: 115568 kB SUnreclaim: 35276 kB KernelStack: 15184 kB PageTables: 20864 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 1385188 kB Committed_AS: 45821668 kB VmallocTotal: 2097088 kB VmallocUsed: 106876 kB VmallocChunk: 1805380 kB TotalCMA: 221184 kB UsedCMA: 4172 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB
Page block order: 9 Pages per block: 512 Free pages count per migrate type at order 0 1 2 3 4 5 6 7 8 9 10 total Node 0, zone Normal, type Unmovable 103 43 23 8 1 0 0 0 1 0 0 617 Node 0, zone Normal, type Reclaimable 0 1 1 0 1 2 0 0 1 0 0 342 Node 0, zone Normal, type Movable 0 0 95 52 12 5 1 0 1 0 109 113084 Node 0, zone Normal, type Reserve 0 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone Normal, type CMA 0 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone Normal, type Isolate 0 0 0 0 0 0 0 0 0 0 0 0 Number of blocks type Unmovable Reclaimable Movable Reserve CMA Isolate Node 0, zone Normal 144 14 690 2 108 0
00000000-04ffffff : System RAM 01080000-01f5b813 : Kernel code 020ac000-025a0fff : Kernel data 05300000-072fffff : System RAM 07300000-07307fff : persistent_ram 07308000-0730ffff : persistent_ram 07310000-07317fff : persistent_ram 07318000-0731ffff : persistent_ram 07320000-07327fff : persistent_ram 07328000-0732ffff : persistent_ram 07330000-07337fff : persistent_ram 07338000-0733ffff : persistent_ram 07340000-07347fff : persistent_ram 07348000-0734ffff : persistent_ram 07350000-07357fff : persistent_ram 07358000-0735ffff : persistent_ram 07360000-07367fff : persistent_ram 07368000-0736ffff : persistent_ram 07370000-07377fff : persistent_ram 07378000-0737ffff : persistent_ram 07380000-07387fff : persistent_ram 07388000-0738ffff : persistent_ram 07390000-07397fff : persistent_ram 07398000-0739ffff : persistent_ram 073a0000-073a7fff : persistent_ram 073a8000-073affff : persistent_ram 073b0000-073b7fff : persistent_ram 073b8000-073bffff : persistent_ram 073c0000-073c7fff : persistent_ram 073c8000-073cffff : persistent_ram 073d0000-073d7fff : persistent_ram 073d8000-073dffff : persistent_ram 073e0000-073e7fff : persistent_ram 073e8000-073effff : persistent_ram 073f0000-073f7fff : persistent_ram 073f8000-073fbfff : persistent_ram 073fc000-073fcfff : persistent_ram 073fd000-073fdfff : persistent_ram 07400000-77ffffff : System RAM c11084c0-c11084d7 : c11084c0.serial c1108500-c110851f : /i2c@c1108500 c1108680-c11086af : c1108680.saradc c11087c0-c11087df : /i2c@c11087c0 c1109880-c110988f : /pinmux c8013000-c80137ff : /mhu@c883c400 c8100014-c810001b : mux c8100024-c810002b : gpio c810002c-c810002f : pull c8100480-c810049f : /rc@c8100580 c81004c0-c81004d7 : c81004c0.serial c81004e0-c81004f7 : c81004e0.serial c8100580-c81005c3 : /rc@c8100580 c8832000-c8832013 : /t9015 c8834430-c883446f : gpio c88344b0-c88344d7 : mux c88344e8-c88344fb : pull c8834500-c8834503 : /defendkey c8834520-c8834533 : pull-enable c8834540-c8834547 : /ethernet@0xc9410000 c8834558-c8834563 : /ethernet@0xc9410000 c8838000-c88383ff : c8838000.canvas c883c3d8-c883c3df : c1108680.saradc c883c400-c883c44b : /mhu@c883c400 c9000000-c9007fff : /dwc3@c9000000 c9000000-c9007fff : xhci-hcd c900c100-c90fffff : /dwc3@c9000000 c9410000-c941ffff : /ethernet@0xc9410000 d0078000-d007807f : /usb2phy@d0078000 d0078080-d007809f : /usb3phy@d0078080 d00c0000-d01bffff : d00c0000.t82x
2つ目はKhadas VIM3 Basicというボードです(Linux 4.9.113 armv7l, Android 9ベース)。Amlogic A311DというSoCで、S922XにNPUというAI処理用のIPを搭載した仕様です。S922Xとピンコンパチとのこと。RAMは2GBです。RAMが4GBのProというボードもあります。
MemTotal: 1925088 kB MemFree: 643640 kB MemAvailable: 1091900 kB Buffers: 9696 kB Cached: 563448 kB SwapCached: 0 kB Active: 405012 kB Inactive: 434112 kB Active(anon): 268152 kB Inactive(anon): 788 kB Active(file): 136860 kB Inactive(file): 433324 kB Unevictable: 2372 kB Mlocked: 2372 kB HighTotal: 1179648 kB HighFree: 36428 kB LowTotal: 745440 kB LowFree: 607212 kB SwapTotal: 262140 kB SwapFree: 262140 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 268356 kB Mapped: 389444 kB Shmem: 1084 kB Slab: 58456 kB SReclaimable: 24384 kB SUnreclaim: 34072 kB KernelStack: 8856 kB PageTables: 22616 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 1224684 kB Committed_AS: 29512728 kB VmallocTotal: 245760 kB VmallocUsed: 0 kB VmallocChunk: 0 kB CmaTotal: 778240 kB CmaFree: 10972 kB VmapStack: 4440 kB
Page block order: 10 Pages per block: 1024 Free pages count per migrate type at order 0 1 2 3 4 5 6 7 8 9 10 Node 0, zone Normal, type Unmovable 39 46 15 4 3 1 1 0 1 1 0 Node 0, zone Normal, type Movable 418 81 32 8 11 8 2 1 1 1 144 Node 0, zone Normal, type Reclaimable 0 1 1 4 0 1 0 1 1 1 0 Node 0, zone Normal, type HighAtomic 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone Normal, type CMA 6 0 0 1 0 0 0 0 0 0 0 Node 0, zone Normal, type Isolate 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone HighMem, type Unmovable 150 76 76 34 17 3 40 10 0 0 0 Node 0, zone HighMem, type Movable 90 186 62 26 10 4 1 0 0 0 0 Node 0, zone HighMem, type Reclaimable 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone HighMem, type HighAtomic 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone HighMem, type CMA 864 430 120 63 26 7 0 0 0 0 0 Node 0, zone HighMem, type Isolate 0 0 0 0 0 0 0 0 0 0 0 Number of blocks type Unmovable Movable Reclaimable HighAtomic CMA Isolate Node 0, zone Normal 17 167 7 0 1 0 Node 0, zone HighMem 73 26 0 0 189 0
00000000-77ffffff : System RAM 00108000-015fffff : Kernel code 01700000-0198cbc3 : Kernel data ff100000-ff1007ff : galcore register region ff3f0000-ff3fffff : eth_base ff500000-ff507fff : /dwc3@ff500000 ff500000-ff507fff : /dwc3@ff500000 ff50c100-ff5fffff : /dwc3@ff500000 ff630218-ff63021b : /rng ff632000-ff633fff : /t9015 ff634440-ff63448b : gpio ff6344e8-ff6344ff : pull ff634520-ff634537 : pull-enable ff634540-ff634547 : eth_cfg ff6346c0-ff6346ff : mux ff634740-ff63475b : drive-strength ff638000-ff639fff : ff638000.canvas ff63c400-ff63c44b : /mhu@c883c400 ff642000-ff643fff : /soc/audiobus@0xff642000 ff64c000-ff64c09f : eth_pll ff800014-ff80001b : mux ff80001c-ff800023 : drive-strength ff800024-ff800037 : gpio ff802000-ff80201f : /soc/aobus@ff800000/pwm@2000 ff803000-ff803017 : ff803000.serial ff805000-ff80501f : /soc/aobus@ff800000/i2c@5000 ff808000-ff80801f : /rc@0xff808040 ff808040-ff808083 : /rc@0xff808040 ff809000-ff809047 : /saradc ffd01008-ffd0100b : eth_reset ffd19000-ffd1901f : /soc/cbus@ffd00000/pwm@19000 ffd1b000-ffd1b01f : /soc/cbus@ffd00000/pwm@1b000 ffd1c000-ffd1c01f : /soc/cbus@ffd00000/i2c@1c000 ffd22000-ffd22017 : ffd22000.serial ffd24000-ffd24017 : ffd24000.serial ffe03000-ffe037ff : /sdio@ffe03000 ffe05000-ffe057ff : /sd@ffe05000 ffe07000-ffe077ff : /emmc@ffe07000 ffe09000-ffe0907f : /usb2phy@ffe09000 ffe09080-ffe0909f : /usb3phy@ffe09080 ffe40000-ffe43fff : ffe40000.bifrost fffe7000-fffe77ff : /mhu@c883c400
 この記事にコメントする
 この記事にコメントする
目次: Android
Androidです。
Androidとは厳密には関係ないけど近しいものたちです。
目次: 一覧の一覧
 この記事にコメントする
 この記事にコメントする
目次: ALSA
デスクトップPCにはスピーカーを繋いでいませんが、たまに音声再生を確認したいことがあります。スピーカーを繋ぎ変えても良いですが、ALSAのループバックデバイスを使うと簡単に音声を転送したり、ファイルに記録したりできます。
ループバックデバイスとは再生した音声がそのまま戻ってきて(ループバック)録音できるデバイスのことです。ヘッドフォンの出力端子を、マイクロフォンの入力端子に繋いでループさせた状態を想像してもらうとわかりやすいと思います。
ALSAのループバックデバイス(aloop)は、ALSAの標準的な機能です。普通の環境だとロードされていないはずなので、modprobeでロードします。
# modprobe snd-aloop $ cat /proc/asound/pcm 00-03: HDMI 0 : HDMI 0 : playback 1 00-07: HDMI 1 : HDMI 1 : playback 1 00-08: HDMI 2 : HDMI 2 : playback 1 00-09: HDMI 3 : HDMI 3 : playback 1 00-10: HDMI 4 : HDMI 4 : playback 1 01-00: ALC1220 Analog : ALC1220 Analog : playback 1 : capture 1 01-01: ALC1220 Digital : ALC1220 Digital : playback 1 01-02: ALC1220 Alt Analog : ALC1220 Alt Analog : capture 1 02-00: Loopback PCM : Loopback PCM : playback 8 : capture 8 ★このデバイスhw:2を使用する 02-01: Loopback PCM : Loopback PCM : playback 8 : capture 8
ロードし終わるとPCMデバイスが1つ増えます。上記の場合は02-xx(02-00と02-01)が増えています。
ループバックデバイスはサブデバイス0が再生用、サブデバイス1が録音用となっています。先ほどの例でいうと、再生時はhw:2,0を使い、録音時はhw:2,1を使います。
$ aplay test.wav -D hw:2,0 Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
#### ファイルに記録する場合 $ arecord -D hw:2,1 -r 48000 -f S16_LE -c 2 test2.wav Recording WAVE 'test2.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo #### ネットワーク経由で送る場合 $ arecord -D hw:2,1 -r 48000 -f S16_LE -c 2 | nc 192.168.1.10 5555 Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
私の家のスピーカーは、今のところROCK64に繋がっています。ROCK64にネットワーク経由で送って、下記のように受け取れば「ほぼ」リアルタイムでデスクトップPCの音声が確認できます。
$ nc -l 5555 | aplay -D hw:0 Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
受け取る方は先頭のWAVヘッダでサンプリング周波数やチャネル数を知ることができるため、-rや -cを指定する必要はありません。指定しても構いませんが無視されるはずです。
「ほぼ」リアルタイムと書いた理由は、上記の方法だと人間が余裕でわかるくらいの遅延が発生してしまうからです。ちゃんと測っていませんが、0.5秒くらい遅れてるかも?これでも簡易的な音声確認としては十分ですし、気にしなくても良いでしょう。
 この記事にコメントする
 この記事にコメントする
目次: ARM
TwitterでCavium Thunder X3はサーバ向け汎用ARM SoCではなくなるかもしれない、という話を見かけました。Cavium(今はMarvellに買収されました)は独自ARM CPUコアを作って頑張ってたメーカーです。
ARM自体はまだまだめげることなく、サーバ向けに売りたい(Armのサーバ向け戦略十年の計は実を結ぶか、新プロセッサ「Neoverse」 - MONOist)ようですが、肝心のARM系SoCメーカーやサーバベンダーがARM系サーバで成功している様子がないです。
以前Qualcomm Centriqも鳴り物入りでサーバ向けARM SoCに参入しましたが、2018年にあっさり撤退(Arm SoCの開発部門を秘かに閉鎖していたQualcomm - EE Times Japan)しています。モバイルの王者Qualcommをもってしても困難な道のようです。
サーバ向けプロセッサはIntelが9割取っているらしいので、崩すのはなかなか容易ではありませんね……。
サーバ向けとして発表されているARMメニーコア系SoCを列挙してみました。年代はチップがローンチされたおおよその時期です。間違ってたらごめんなさい。
こんな感じですかね?SC2A11はホームページでサーバ向けと謳っていたので、リストに入れてます。でもCA53コアなので、性能的にはThunder X2辺りと並べるのはちょっと厳しい……かな?
 この記事にコメントする
 この記事にコメントする
目次: ARM
先日KADHAS VIM2, VIM3を購入したため、ARMボードがさらに増え置き場がなくなりました。既存のボードをコンパクトに収納できないかと画策し、目を付けたのがROCK64です。現在ROCK64は純正ケースに入れて使っていますが、ギリシャの神殿を思わせる立派な柱と、無駄にでかいアクリル板のせいで、すっっごい邪魔です。
ROCK64はRaspberry Pi 3とほぼ同じ大きさですから、Raspberry Pi 3のケースを流用できるはずです。
改造のベースになるケースは、TinkerBoardやRaspberry Pi 3の格納で活躍しているPhysical Computing Labの3ple Decker Raspberry Piケース(公式サイトへのリンク)です。
Rasberry Pi 3は電源がUSB micro Bですが、ROCK64はACアダプタなので、全く形が合いません。アクリルケースの穴を削って広げる必要があります。もう一か所、ROCK64の個体差か(or単に設計の問題か?)ヘッドホンジャックがケースとズレていて、プラグが刺さらないため、これも直さないといけません。
削り方はリューターにプラスチック用のビットを付けてゴリゴリ削るだけです。厚さも面積も大したことないので、力業でどうにでもなると思います。アクリルを削ると変なにおいがしますね。焦げてるのかな……?
ケースを削り終わりました。ROCK64の端子がちゃんと外から見えています。
元よりROCK64用のケースではないので、様々な不都合が発生します。
Pi P5+ Busが使用不能になる点は諦めました。Rasberry Pi 3にはないピンヘッダなので致し方無しです。このピンヘッダから引き出していたS/PDIFが利用不可能になりました。さよならS/PDIFさん。
PWR, RESETボタンはケースを開ければ押せますが、面倒です。今後はPWRボタンに頼らない運用を考えるべきでしょう。
ボードが固定できない問題はどうにもなりませんでした。microSDの上部を抑えるケース側のツメがうまくハマりません。
もう少しきちんと調べてみると、ROCK64はRasberry Pi 3よりmicroSDスロットに厚みがあるせいで、microSDの上部を抑えるケース側のツメがうまくハマらないようです。
スロットの厚さはどうしようもないので、泣く泣くケース側のツメを折りました。
ツメがないので、microSDカードがケースに引っ掛かってギリギリケースに固定されている状態です。ROCK64の40pinのピンヘッダ(Pi-2 Bus)にジャンパケーブルを抜き差しすると、microSDにかなり力が掛かります。これは良くないですね……。
Pi-2 Busへのケーブル抜き差しは結構固いため、そのうちmicroSDスロットが変形するか、microSDが折れて壊れると思います。幸いなことに、今は頻繁にピンヘッダのケーブル抜き差しはしませんから、しばらくこの状態でも使えるでしょう。
 この記事にコメントする
 この記事にコメントする
目次: 車
先週、突然知らない番号から電話が掛かってきました。何だか焦った様子でした。要約すると「アパートの駐車場で隣に駐車している者です、駐車しようとして、あなたの車にぶつけてしまいました」とのことでした。車の様子を確認したところ、見事にバンパーの右前が取れていました。ああー……。
後日、保険屋さんと修理屋さん(スーパーオートバックス)から電話があり、車を引き取りに来る日時等を決めました。そして今日、レガシィさんはフロントバンパー修理のため旅立っていきました。
修理屋さん曰く「右ライトもAssy交換で新品になるだろう」とのこと。新品交換後の右ライトに対し、古ぼけた左ライトの明るさがアンバランスになるのはうまくないので、左ライトの研磨もお願いしました。残念ながら左ライトの研磨は保険が効かず自費になりそうですが、曇っていたライトが明るくなるから良しとしましょう。
代車はホンダのフィットでした。
総じて良い車だと思います。レガシィとの違いとしては、
昔のフィットに乗ったときアクセルオフ時のエンブレが急すぎて車酔いしたので、正直好きな車ではなかったのですが、今のフィットは素敵な車です。新しい車って確実に良くなってますね。
ADAS(前車の車間検知、車線逸脱の警告)も搭載されていて面白いです。たまに誤検知?するのか、何もないところで突然ピー!と警告音が鳴ったり、車線逸脱の警告とともにハンドルがンゴゴー!って言い出すのはご愛敬です。
 この記事にコメントする
 この記事にコメントする
目次: Zephyr
最近のRISC-V向けQEMUでspike, virtを起動すると、下記のようなエラーで怒られてしまいます。
$ qemu-system-riscv32 -nographic -machine spike -net none -chardev stdio,id=con,mux=on -serial chardev:con -mon chardev=con,mode=readline -kernel zephyr/zephyr.elf qemu-system-riscv32: Unable to load the RISC-V firmware "opensbi-riscv32-spike-fw_jump.elf"
このエラーの原因はQEMU RISC-V向けの仕様変更によるものです。machineがspike, virtのときに、自由にBIOSを選べるように変わりました。ですがZephyrを起動する際には、特にBIOSは必要ないため、noneを指定すればOKです。
$ qemu-system-riscv32 -nographic -machine spike -net none -chardev stdio,id=con,mux=on -serial chardev:con -mon chardev=con,mode=readline -kernel zephyr/zephyr.elf -bios none *** Booting Zephyr OS build v2.2.0-rc1-123-gcaca3f60b012 *** Hello World! hoge
ZephyrだけでなくQEMUも日々進化しているのですね。
 この記事にコメントする
 この記事にコメントする
 wiki
 wiki Linux JM
 Linux JM Java API
 Java API 2002年
 2002年 2003年
 2003年 2004年
 2004年 2005年
 2005年 2006年
 2006年 2007年
 2007年 2008年
 2008年 2009年
 2009年 2010年
 2010年 2011年
 2011年 2012年
 2012年 2013年
 2013年 2014年
 2014年 2015年
 2015年 2016年
 2016年 2017年
 2017年 2018年
 2018年 2019年
 2019年 2020年
 2020年 2021年
 2021年 2022年
 2022年 2023年
 2023年 2024年
 2024年 2025年
 2025年 過去日記について
 過去日記について アクセス統計
 アクセス統計 サーバ一覧
 サーバ一覧 サイトの情報
 サイトの情報