Rock64にEPGStation

　CPUパワー的にはいけんじゃないの?とNanoPi NEOにEPGStation載せてみたまでは良かったんですが、結局、録画はできそうなもののエンコードに難があって、rateは高く設定しなきゃなんないわリップシンクできないわということで、これじゃアカンね…　結局、Allwinner系SoCではアクセラレーションかけられず、で、ダメなんだね(泣)。はぁ…、NanoPi NEOでできそうなアプリが減っていく…。

まぁ、ラズパイ3Bで本線は確保してるんで所詮はバックアップなんですが、そうは思いつつも、ちゃんと録画性能ないものに電気食わせてても仕方ないので、やはりrock64を持ち出すことにしました。これならラズパイ3Bよりも安くて速いし…

Rock64 + Raspi3用ケース

ボードサイズは同じだし、USBポートの数が違うけどHDMIなどの位置も同じだから、電源コネクタの違いさえ加工すればラズパイ3B用のケースに収まるよね、ということで、ラズパイ用のケースを流用してるんです。

今回もそれでいこうと思ってピックアップしたケース、3段重ねタイプでした。

入れてみると、この、真ん中にある「中層」の薄い部分、ラズパイとrock64の部品配置の違いで完全に邪魔であることが判り、あえなく総撤去。あとはそれに加えて、電源口の違いを修正すれば収まってくれます。

ということで準備完了。なお、RK3328は、経験上それなりに熱くなるので、効果のほどは微妙ですが、放熱器を乗せてあります(下の銀色の箱はHDD)。これでも、もしかすると夏場、h.264エンコードの際に熱くなりすぎるかも知れません。

これでrock64は3台目になるんですが、今までとは異なり、armbianをインストールしてみました。Armbian rock64には、現時点でLinux5系のイメージと、Linux4系のLegacyと銘打ったイメージがあります。私、HDMIモニタを使ってなくてHDMI - VGAアダプタを使っているんですが、Linux5だと、それを使った表示ができません。HDMI直結なら問題ないことは判ってるんですが（HDMI付きのTVでは問題なく表示できるがTVは家族共用ですから…）、基本ヘッドレスとはいえ場合によってはHDMI - VGAを使用するので、Legacyを使います。ここまでは問題なし。

で、チューナーは、PX-S1UDです。

ん？チューナーが動いてない…

mirakurunまでインストールしてチャンネルスキャンしてみると、何も検出してくれません。おやや…とlsusbしてみると、ちゃんとチューナーは見つけてますが、dmesgしてみるとreturn code -12で正常に立ち上がれていません。

　smsusb:smsusb_init_device: smscore_register_device(...) failed, rc -12

　smsusb:smsusb_probe: Device initialized with return code -12

　smsusb: probe of 2-1.4:1.0 failed with error -12

しかしちゃんと先人は居られるもので…ありがとうございます。

久しぶりのカーネルビルド???

まだLinux2.xの初期以前の頃は、PCにLinuxインストールするにしても、PCIカードのデバイスドライバの存在非存在や、ある機能のサポート有無がドライバのバージョンに依存していたことがあったり、ドライバのサポート状況を見てPCIカードを選んだりドライバソースを更新するなどで、比較的頻繁に、カーネルのreconfigやbuildをやっていました。もうだいぶ昔のことで、2.x後期頃からそのような機会も大幅になくなり、ほぼ一回インストールしたらカーネル再構築することもなく…と、長らくエンドユーザーに徹しておりました(汗)

しかしまぁ、カーネルソースにパッチを当てる以上buildは必須なので、armbian-configを通じて使用しているカーネルソースをダウンロードしパッチを当てます。smsusbおよび関連するモジュールのみの問題のはずなので、カーネル自体を入れ替える必要なく、そのため今走っているカーネルと同じバージョン情報でモジュールをbuildする必要があります。.config保存しておいてmake mrproper、.config戻してmake oldconfigするのは今も変わらず。さて、走行しているカーネルのEXTRAVERSIONは、というと…uname -rした結果は4.4.213-rockchip64、と言うことなので、はいはい、じゃEXTRAVERSIONは-rockchip64、それを渡しつつmake modules_prepareしてmake modules。で、できたモジュールをmodprobeしてみると…

smsmdtv: version magic '4.4.213-rockchip64+ SMP mod_unload aarch64' should be '4.4.213-rockchip64 SMP mod_unload aarch64'

え”？俺"+"なんてつけてないんだけど…。

.scmversion

実はこれ、まったく知らなかったんです…なぜ?機構的には古くからあるようなのに。

いつもカーネルイメージ全体作り直すか、基本debian使いなので、debianのソースを使用し更新するモジュールだけdebianの仕組みの中で作り直していたから、意識する必要なかったんですかね…。

ということで、.scmversionをtouchして、make mrproperからやり直し。

クロス環境ではなくローカルbuild、かつ、後で気づいたんですがw、シングルプロセスでbuildしてたので、moduleだけとはいえ数時間かかるプロセス。

最終的に、同じversion magicのモジュールを手に入れることができました。これでチャンネルスキャンを行わせてみると、今度は正常にスキャンできました。

これで、ラズパイ3Bコケても、比較的容易に中継ぎ登板できるかなと思います。

さて、この次は、Pi Zeroではprime video再生できなかったkodiか。それもまたrock64かな…。

 

2021/5/25追記

 諸般の事情でこの記事の後、PX-S1UDを使用した録画機は、PineA64に移っていました。それはもうすんなり動いたんで書くこともなかったんです。しかし、そいつに使っていたHDDが寿命を向かえていることが判ったため、急遽新たなレコーダーを起こす必要にかられ、rock64を再登板させて引き継ぐことを考えました。

当然、当時のセットアップ状況が残っているわけもなく、新たなインストールです。

・USB3の問題　

今から調達するとなるとUSB3を前提にしたくなるわけで当然そういう選択になります。rock64自体、USB3.0対応しているから大丈夫だよね…。…。…。…。ところが、動作が怪しい。ちゃんとUSB3で認識するんだけどformatかけると停止、というか、エラーを発しだす。

これがまたx64なPCでは確実に動くんで、HDD自体の不良ではありません（ORICOの2.5"のケースに6G SATAのHDD)。

（時系列が実際に起こったこととは入れ替わって書いてるんですが、順序としてはPineA64にこのHDDをつないだとき、動作しなかったんですよ。そのあとx86に持っていってみて問題ない、ということは、USB3 HDDのサポートに問題あるかも？ということで、rock64が再浮上したのでした。）

 

となると…また電源問題かよ。

 

残念ながら手元にはセルフパワーなUSB3 hubはなく、USB2しかない。しかし、PineA64ではUSB2で性能的な問題はなかったので、USB3 hubを調達するまでのつなぎでUSB2で行くことにする。

・OS的問題

Rock64の場合、ちょっとケチった環境でモニタにHDMIがないからと、HDMI - VGAあるいはHDMI - DVIアダプタを使おうとすると、ayufan氏のインストールイメージ以外ではHDMIがそれらアダプタに適した出力をしてくれない。そのため、armbianなどの場合ヘッドレスで使うしか今のところない。

この問題を知る以前から、microSDブートではなくHDDブートのためにayufan氏のイメージを使用してきたけど、安定版としては4.4.190と、だいぶ古いカーネルを使うことになり、かつ、一部のUSB機器を接続するとクラッシュを起こす。そのため、ちょっと冒険して5.12.0のイメージを使うことに。

ただ、xubuntuのイメージを使ったはずなのに、32GのmicroSDはフルフルに。仕方ないので、minimalにxubuntu-desktopを追加インストールする形でセットアップを行う。これなら32GのmicroSDはスカスカです。

・EPGStation v2

もう数回セットアップしたことになるmirakurun+EPGStation、手順だけ、当時から参照させてもらっているサイトのお世話になれば大丈夫かな…と思いきや、EPGStationがv2と新しくなっている。

セットアップマニュアルにあるとおりにやっているはずなのに、vue-cli-service not foundでbuildが完了しない。node_modules消して〜とか試してみるがダメ。どうも"Javascript heap out of memory"で落ちている、ということで、最終的に、

export NODE_OPTIONS="--max-old-space-size=1024"

が必要、と知るまで、一日掛かってしまいました。これでなんとか動きだしました。 rock64に都合3G swap割り当ててもダメだったので、オンメモリで1G以上必要だったのでしょう。

・USBの性能的問題

ところがお試し録画してみると、録画したものは全然ダメダメ、画面の真ん中くらいしかちゃんと動画再生できてない(後はブロックノイズ)。USB2って一応480Mbpsあるんで、HDDとチューナー同じhubにぶら下げても大丈夫でしょってやってたんですが、それって実はPineA64時に踏んだ轍で、パフォーマンス的にダメなんです。なので、結局USB3ポートにセルフパワーhubをつけてHDD、USB2ポートの一つにPX-S1UD、もうひとつのUSBポートにHID系のものをつなぐ、という構成で、ようやく運用できるようになりました。

最終的には、セルフパワーのUSB3 hubを持ってきてUSB3につながないと、HDD性能が生きないので、近いうちに調達する事にします。さすがに桁が違うのでね…。

・余談

セットアップ時にあんまり考えず、mirakurun+EPGStationをセットアップして最初立ち上げ番組表みたとき、時間が「？、UTCになってる…」ということでtimezoneを直したところ、すでにEPGを取得済みの部分は16時間ずれて解釈されたまま残ってしまうことが判りました。当然、録画失敗します。

EPGをフラッシュする方法が判らず、しかしまぁそのうちちゃんと同期するでしょ、と放っておいたら、翌朝まで16時間ずれ番組表が残ることになってしまいました…気をつけましょう。

 

 

NanoPi NEOでサーバー、再び

　以前、NanoPi NEOでNFSサーバーをやらせようとした顛末を書いたことがありますが、その時、「約一日稼働すると、どうもhddが止って、再度スピンアップできない模様で止ってしまう。しかしこれ、hdd側の自動停止なのか、Linux側によるUSBの自動停止なのか釈然としない。」ということで諦めた経緯がありました。

BDレコーダーが壊れた時、TS抜きのプラットホームとして、無論NanoPi NEOも検討してみていました。その時の事。

インストールもできたし、ではパフォーマンスの問題を見よう、と思い走行させておくと、早くて数時間、長くても一日程度で止まってしまいます。ログ見ても原因究明につながりそうなエラーはなし。うーん、困った、とは思いつつ、試験的に録画実施してみて、h.264エンコードさせてみると「おそっ」。デフォルトのrate = 4.0では到底終わらずその倍必要（おそらくffmpegで、H3ではアクセラレータがサポートされてない）。まぁそれも仕方ないかとは思いつつ、それでも少しは時間改善図れるか？と思い、クロック速度を調整してみたりしていたところで、システム停止する直前にあったと思われるログのタイムスタンプが異常であることに気づきました。Syslogを前回起動以後今回の起動まで通しで見ると、ある一定のところまでは、概ね正しいと推定される時間つまり起動した時間より後なのですが、停止してしまう際には、かなり過去の時間が記録されています。はてこれは…。

ntpの関係かも?などと確認してみるもちゃんとupdateの記録はあるのですが、その後狂うことが確認できました。

armbianmonitorでCPUクロックを継続的にモニタしてみると、暇な時にはクロックを落とし、録画始まったりすると、ちゃんとフルパワーになります。しかし、クロックを落としたあとで、時間もおかしくなるケースがあるようです。なんともはや。

ということで、クロック制御を止めて固定で走らせると、一週間でも問題なく走ります。

これは、ハードウエアとしてのNanoPi NEOの問題なのか、そのサポートにおけるLinux上の問題なのか、追求はしてはおりませんが、おそらく、NFSサーバーをやらせたときに停止する問題も、これなんじゃないかな…。

auひかり テレビサービス顛末

　前回の、BDレコーダ壊れるでちょっと触れた、不具合の雰囲気があるauひかり　テレビサービスのSTB、何が起こっていたかというと、数分程度で受信できなくなる、ほぼ自動復帰しない、というものでした。最近あんまり視聴・録画してなかったので、具体的にいつからか？については明示難しいんですが、今年の正月頃までは問題なく一時間ドラマを録画できていたので、その頃までは問題がなかったものと思います。

最近になって録画済みの整理の上で新たな録画予約をしたらこの調子。

宅内ネットワークの不備であれば、他にも影響出ておかしくないのですが何も無く、ビットレートは異なるとは言え長尺のyoutubeなりAmazon Primeなり見ても切れることは無く、こりゃau内（というかテレビサービスのストリーミングサーバー側の)問題でしょ、とは思いつつ、auに問い合わせ。

で、異常対策の通常ルートであろう、STB、ホームゲートウエイ、ONUと、全とっかえして機器が一新されても状況が変わりませんでした。STB交換・ホームゲートウエイ交換の際は、代替機を送ってもらって機器交換ですが、それで状況改善しないのでサービス担当の方がこられて状況確認、そのときONU交換して光信号レベルにも問題ないことは確認されたのですが解決策無く、auネットワーク内の問題を確認してもらうことでその時は引き上げていただきました。

au側確認頂いてそちら問題なく…ということで再度確認に来訪頂いて、ちょうどその際問題発生で現象確認、一通り、宅内ネット、光側レベルなど再度確認頂いてやはり異常はなく、ONU、ゲートウエイ再起動すると…　何と今度は30分ほど確認しても切れないではないか！　え〜っ？一体何が起こったの??　サービス担当さんと相談の上、様子をみることで同意し、引き上げていただきました。

そしてその後…

宅内の機器がすべてネットワーク不達となるので確認したところ、なんと、ゲートウエイ内側つまり宅内側のネットワークアドレスが変わっています。ははぁ…、サービス担当さんゲートウエイを初期化したな、と思い、改めて、元々使用していた設定に戻すと、もちろん問題なく宅内機器は復帰します。じゃSTBは？と見ると、改めて、切れるように…。

え”？？？？

ゲートウエイ設定初期状態に戻すと、STB切れなくなります。おぃおぃ、それってやっぱりどこかのau内ゲートウエイなりNATなりがとち狂ってるってことじゃねーの？とは思いつつ、だいぶ面倒でしたが、宅内機器のネットワークアドレスを変更して、元の鞘に収まりました。

さて、どうやってauに報告すっかな…。

BDレコーダ壊れる

以前、BSアンテナ用供給電源が…という話をしたことがあるBDレコーダーですが、とうとうHDDが壊れたようです。まだネット配信が一般化する前の、ethernet端子がない、HDD容量も500Gのもの。HDD交換の手立てをいくつかネット上で見つけることはできるものの、なんにしても録画済み番組は救済することはできません（あぁ…、Casiopea 3rdのライブ、落としておくんだった…）。

仕方ない…ということで、BDレコーダーを物色してたんですが、世間様は4K流行り、でもなぁ〜、ピンとこんのや、高いばっかで…　じゃぁメディアサーバー系HDDレコーダーは？と思うと、TV側に機能集約されて外付けHDD対応が進んだためか玉数少なく、BDレコーダーと価格帯イメージもあまり変わらないという状況。

EPGstation

　一通り逡巡したところで思い出したのが、TS抜き。

チューナーは、手元には古いPCI品しかなく、探してみると、地デジオンリーのUSB 1ch.タイプは結構容易に入手できる、ということで、アマゾンからカードリーダーともに調達。お休み中のRaspberry Pi3Bを引っ張り出して、通常のraspbianをmicroSD使ってインストール。録画データ用に、ホームディレクトリサーバー用にプールしていた1T外付けHDDを用意。B-CASは、もうドライバサポートが終了し、ほぼ使い道ないPCIチューナーカードのものを持ってきて、先人の記事を元にEPGstationをセットアップ。この領域は、ほとんど経験がなく、先人の皆様が頼り、ありがとうございますm(_ _)m

…、ということで、稼働させてみると、プラットホームがPi3ということもあるのだろうけど、ライブと、録画データのTS再生には難があるものの、H.264にエンコードしてしまってあれば、問題ありません(当然か）。おぉ、これは使えるよ。

ただ、録画後エンコードのCPU負荷がなかなか高く、その最中に録画が入ると、悲しい事態になるかもしれず…　ではあるのですが、BDレコーダーが壊れた状況のままにしておくこともできず、とりあえずこのまま運用についています。

Kodi、まだ、うちでは、おまけ以上にはできておらずですが…

　EPGstationは、ブラウザでアクセスして録画・再生するので、通常のTVを使って操作するには少し工夫が必要、ということで、Pi ZeroWを、LibreElecを使ったkodi機として仕立てました。ラズパイはユーザー層も広いようで、LibreElecコミュニティーでも、先陣を切りサポートされるようです。LibreElecサイトでリリース情報を得られます。後で述べる点と合わせて、今後整備、と言うところです。

本格化するには

　もともと、BDレコーダーはマルチチューナー機ではなかったので、1ch.チューナーで運用する事自体には家族からクレームはないのだけども、試験として調達した、地デジオンリーな状況には不満の声があがってます。ということで、地デジ/BSタイプのチューナーの調達、が一つ。

もう一つはPi3、HDDレコーディングするとは言えUSB2.0、が、録画と再生が重なった時には不安が出てきます。USB3搭載のボード、Pi4とか、うちのサーバーとして動いているrock64などに交換する必要がありそうです。使用メモリ自体は、1ch.録画で運用している分には1Gで余裕があるようです。念のため、swapエリアを1Gに広げてあるのですが、ほぼ使用していません。もし、マルチチューナーにする場合は、応じたメモリ空間が必要になるかも知れません。

※ 8/16追記

　BS/CS録画ニーズが高く、一ヶ月も経たないうちにPX-W3U4も仕入れる羽目に。この本体にはカードリーダーが内蔵されてるんですが、こいつはまだLinuxでは使えない、ということに気づかず、一日（と、都合4時間ほどの録画を）無駄にしました…。

その他の機器

　壊れたBDの代わりについて逡巡していた時、EPGstationによる地デジ対策に加えもう一つ頭に浮かんだのは、auひかりテレビでした。これ、地デジを通してないなど登場当初は使い勝手に難ありではありますが、CS/BSで放送されているチャンネルの多くはカバーされているし、せっかく契約しているのだから（現住居に引っ越してくる前はitscomを使っていたので、auひかり契約時、ひかりテレビチャンネルに、子供向けアニメチャンネルがあることもあり、それほど深くは考えずに契約もした）、使わない手はありません。いつの間にか、TELASAも見れるようになってる！と思ったら、ビデオパスがTELASAに名前変わったんね…。

契約当初はまだ「スマホでストリーミング見る」時代には早く、かつ、DTCP-IP？DLNA？という頃だったこともあり、Dixim BD Burnerを使ってはいたんですが、子供向けチャンネルから卒業していくと、そのサービス切れを機会に、無駄金を貪って（スミマセン…）いる状態でした。つまり、このSTBで録画したものを、メディアに落としたりするためには、DTCP-IP対応のHDD/DVD/BD機器が必要になるため、ぐるぐる逡巡することになるメニューの一つになっていました。BD burnerの終了後、なるべくローコストでそこをクリアするには、SonyのPC TV Plus、それは判っていたんですが、ようやくそれを調達。

残るは、DTCP-IP配信。これ、kodiで対応できるはずなのですが、放送中番組リストの取得、録画済み番組リストの取得はできているものの、再生することができていません。ただ、今現在使っているSTBには不具合の雰囲気あり、交換機材を送ってもらえるので、その後検討、となりそうです。

…、この領域は、今やSTB自体android機だったりしてまさに組み込み機の世界で、むかしチョロッと関わったこと無くはないのだけど、全然遠い世界になってましたね…。だいぶ取り残されている感じです。

追記

　kodiはAmazon Primeも対応してたよね、と思い、プラグインを足してみると、「ARM6はwidevinecdmサポートしとらんけんね、再生できんとよ。」と言われる。kodiのwidevineサポートを調べると、どうやらPi Zero及び初代Pi(つまりARM11機)が該当する模様。あうぅ…EPGstationで録画したものの再生には問題ないのに、どうやらPi3以後か、他にHDMI内蔵されてるボードを探さないとならなそうです（はっ、BBB…???いやいや…）。

NanoPi NEOにMPD

モチベーション/2020年6月21日

 その昔、3.5"サイズのx86ボードにmpd(music player daemon)を載せて音楽サーバーやらせてたんですが、HDDがお亡くなりになって以後、代替を用意することなく、だったのですが、それをNanoPi NEOで再現してみようと思います。

最近のNanoPi NEOには、CVBS(NTSC)出力も追加されているようですが、アナログオーディオインターフェースも、2.0mmピッチのスルーホール5pinで用意されています。

最初、これを使うために、PCで見るようなコネクタを搭載しようと用意したんですが、狭い、UART0とUSBポートの隙間で、干渉してしまうため、直接半田付けしてライン出力を引出しました。元々ランドがあんまり大きくないんですが、加えてGNDポートはサーマルランドになってないのか、なかなかはんだがうまくのってくれなかったんですがそれはさておき。

しかしこのライン出力は、NanoPi NEO回路図を見ると、H3端子が直接ACカップリングされているだけです。これじゃ多分、パワー足んないよね、とはおもいつつ、とにかく、PC用の、アンプ内蔵スピーカーをつないで、音を出してみることにします。

NanoPi NEOのオーディオ

　FriendlyARMのWikiにもかかれていますが、確認するもっとも簡単な方法は、alsa-utilsを使ってaplay -lかと思います。確認してみると：

user@nanopineo:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Codec [H3 Audio Codec], device 0: CDC PCM Codec-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
user@nanopineo:~#

となってます。

MPDと設定

　MPDはごく普通に、aptでインストールしてやります。設定も、あちこちに先人がおられるし、特に難しいことは不要なはずです。ただ、うちでは、ファイルサーバーにまとめて音楽データも置いてあるので、それをautofsを使ってマウントするようにしてやり、それを参照します。

/etc/mpd.confには、aplay -lで確認した結果を反映してやります。

audio_output {
        type            "alsa"
        name            "My ALSA Device"
        device          "hw:Codec,0"
        mixer_type      "software"
}

動作確認

　MPDのクライアントアプリケーションとしてmpcというCUIアプリがありますが、それだけではなくスマホからも接続してみます。

MPDを動かすNanoPi NEO以外の、スマホを含む端末からアクセスしたいので、mpd.confのbind_to_addressは、個別のアドレスが判っていない場合anyとするようです。ネットワークアドレス使えないのか試してみましたが、エラーになってしまいます。何か方法あるんでしょうか…。

で、rock64からアクセスしてやると：

foo@rock64 >> mpc
volume:100%   repeat: off   random: off   single: off   consume: off

foo@rock64 >>

おーOK。なので、updateコマンド入れて、データベース(音楽リスト)を更新してやります。

次、スマホ。Android向けにもiPhone用にもいくつかクライアントがあるようですが、Android向けにMPDroidを試しました。これはAndroid10よりも前のバージョンまでの対応のようですが、動いてくれているので、試験用途としてはOKかと思います。

で、さっきmpc側でupdateしたので、MPDroidでつないでやると(サーバーアドレスを設定してやります)、サーバー上にある音楽データのリストを取れます。MPDroidでもサーバーデータはアップデートできます。

リストから適当に選んで再生してやると、NanoPi NEOにつないだスピーカーから音が出ます…、が…、案の定ゲインが全く足らねー…(泣)。ボリューム最大で、スピーカーに耳近づけてヘッドホンで聞いてるようなレベルです。こりゃちゃんとプリアンプ入れてやんなきゃダメだぁ〜。

がまぁ、なんにせよちゃんと動いてくれてますんで、アンプ用意したら運用に入りたいと思います。

あとは、サーバーに音楽データをアップロードするところを用意して、子供らでも使えるようにすれば完成、ですかね…。

アンプ/2020年8月9日

　8/1に何やらChina Postから配達されてきたものが。はて？まさか、はやりの「種」…？

出てきたのは…、そうそう、こないだAmazonでオーダーしたアンプだ!

案内があったのは月末〜9月頭だったので、ほぼ4週間も早く届いたことになります。サイズイメージのために、となりにCR2032をおいてみました。

アンプをAmazonで探してみると、出力段アンプはいろいろ見つかるんだけど電源が大抵12Vだったりして、あんまり考えずにこういうところで使える、5V以下のものって意外と球数がなく、ヘッドホンアンプから選んでみました。で、こいつをNanoPi NEOのオーディオ出力につないで音を出してみると…

あれ？カラオケ？

つまり、左右どちらかが逆相になっている?いやいや…。んー、それにこのハム音は…

まずハム音。NanoPi NEOコンソールとして使っているUSB-UARTが、どうやら接続先からもらってきているらしいので、それは最終的にはなくなる、と。

PC用のアンプ内蔵スピーカーでテストしていて、こいつがUSB端子から内蔵アンプ用の電源を得るタイプのものでそれもちょっと原因ぽく、NanoPi NEO自身のUSBポートにしてみると、ACアダプタがたまたまあまりノイズを吐かないのか、調子良さげ。

そうなると、USBポートを取られてしまうので、USB Wi-Fiでネットにぶら下げていたものを一旦有線にしないとならず…しかし、まずは…

NanoPi NEOを有線にして、も一度試すと…あら不思議。ちゃんと鳴るじゃん！

USB Wi-Fiに戻すとカラオケに。んー。どうやらUSBの使い方に影響を受けるようです。

多分、チップレベルでの設定に関係してるんだろな。

となると、最終型は、有線LANで使うか、あるいは、I2SにDAC持ってくる形にしないとならんのかな…。まぁ、とりあえずは有線でちゃんと動くようだし、箱を何とかしましょうかね！