目次: ROCK64/ROCKPro64
以前(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だと思って再生してしまい、バリバリバリ!!という凄まじい音量のノイズが再生されることがあります。お試しの際は、音量を小さくしてからテストしてください。
目次: ROCK64/ROCKPro64
今更ですが、メモしていなかった気がするので、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はアナログオーディオを使いたい場合に有効にしてください。
目次: ROCK64/ROCKPro64
去年だったか、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をサラウンドモードにすると、テレビから全く音が出ませんでした。がっかり。
目次: 車
コロナ騒ぎが始まって、遠出することもなくなり、かれこれ4か月以上?車に乗らず放置していました。
骨折した奥さんを整形外科におくるため、JAFさんに車のバッテリー上がりを直してもらったんですけど、バッテリー電圧がなんと1Vしかありません。えー??
車のバッテリー(鉛蓄電池)の端子電圧は12V程度が正常ですから、10Vの見間違い?と思いましたけど、何回見ても1.0Vでした。乾電池だってもうちょっと電圧あるでしょう。
今まで何度となくバッテリー上がりさせ、バッテリー破壊もこれで4度目(2007年、2013年、2016年、2020年)ですけど、1Vまで下がったのは初めてです。
割とお高いGS YUASA 80D23L大容量バッテリーを使っていたのですが、いかなるバッテリーであろうと、このレベルの過放電には無力ですね。エンジン掛かった後も全く充電される気配がありませんでした。
近所のイエローハットまでバッテリー交換しに行く道中が一番嫌でした。
こんな状態で、産業道路〜環七〜第二京浜と走るのはかなり怖いです。無事に辿り着けて良かったけども。
また懲りずにPanasonic 85D23Lの大容量バッテリーに交換しておきました。3万円くらいしました。たっけぇ……。今年は車検もあるし、全然乗ってない割に金ばっかり掛かってます。不思議ですね。
メモ: 技術系の話はFacebookから転記しておくことにした。
目次: ROCK64/ROCKPro64
最近はたくさんのARMのシングルボードコンピュータ(SBC)が市販されています。2019年以降のボードも追加してみました。値段は変動するので参考です。
古い世代のSoCを採用したボード達です。
以前(2019年5月15日の日記参照)載せた情報も含んでいます。
< | 2020 | > | ||||
<< | < | 08 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | - | - | - | - | 1 |
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 | - | - | - | - | - |
合計:
本日: