link permalink

link 編集する

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 用のテスト機材

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 用のテスト機材

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 をサラウンドモードにすると、テレビから全く音が出ませんでした。がっかり。

[編集者: すずき]
[更新: 2020年 8月 2日 22:39]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

RockPro64 の HDMI から音を出す

今更ですが、メモしていなかった気がするので、RockPro64(Rockchip RK3399 搭載)で HDMI Audio を有効にする方法です。

方法は簡単で Linux の CONFIG_DRM_DW_HDMI_I2S_AUDIO と、CONFIG_GPIO_SYSCON を有効にすれば良いです。8/7 時点の linux-next のツリーでは、make defconfig すると、GPIO_SYSCON は n で、ビルド対象外になっています。手動で下記の設定を有効にする必要があります。

linux-next で有効にするコンフィグ(元から有効になっているものも含む)
  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 はアナログオーディオを使いたい場合に有効にしてください。

[編集者: すずき]
[更新: 2020年 8月 8日 14:14]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

SPDIF/HDMI ビットストリームパススルー

以前(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%)


HDMI に Dolby AC-3 をパススルーで出力

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%)


HDMI に LPCM で出力

その他の注意点として、受信機側がパススルー出力で送った圧縮音声に対応していない場合、LPCM だと思って再生してしまい、バリバリバリ!!という凄まじい音量のノイズが再生されることがあります。お試しの際は、音量を小さくしてからテストしてください。

[編集者: すずき]
[更新: 2020年 8月 10日 20:22]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

エアコンが落ちそうで怖い

Twitter で「これ便利」と紹介されているのを見て知りました(製品紹介へのリンク)。エアコンハンガーというそうです。見た瞬間から「うわー!やめてくれー…エアコンは物干しじゃない」という感想しか浮かびません。

エアコン据付板の耐荷重はマチマチで、耐荷重ギリギリの可能性もあります。ハンガーの耐荷重(5kg)を追加で吊って、エアコン室内機が頭の上に落ちてきたら大ケガします(室内機の重さは 10〜15kg)。

パナソニックのエアコン説明書にある山盛りの注意書きを見ましたが「エアコンにモノを吊り下げると、落下しケガする」とは書いていませんでした。家電のユーザーはメーカー想定を超える壊し方をすることは、一応知ってましたが、実例を目の当たりにしたのは初めてです。全く嬉しくないですね。

エアコンハンガーの利用で、事故やケガにあっている人がいないことを祈ります……。 ちなみに、エアコンハンガーのメーカー注意書きに、

「下地がしっかりしていない壁に取り付けられているエアコンには使用しないでください。エアコンが落下する恐れがあります。(例: 下地にベニア板の無い石膏ボードなど)」

と言い訳が書いてありますが、一般人が壁の素材と下地を知るわけないでしょう?本気で言ってるのか??

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

[編集者: すずき]
[更新: 2020年 8月 8日 14:24]

コメント一覧

  • hdk 
    言い訳がいいですね。実際にもし石膏ボードをボリボリと壊して落下したとして、室外機との接続があるから床までは落ちないんですかね。傾くくらいで済むのかな。 
    (2020年08月08日 14:57:39)
  • すずき 
    室内の銅配管は段々硬くなるので、床に落ちることはないと思います。
    とはいえ、うちのように結構室内の配管が長いと、頭には当たるかもしれないですね。 
    (2020年08月10日 17:53:18)
open/close この記事にコメントする



link permalink

link 編集する

Wikipedia

Wikipedia に寄付しました。といっても 5,000円ですけども。

Wikipedia の運営元(Wikimedia Foundation, Inc.)は広告なしで Wikipedia のような巨大システムを維持していて、さすがだと思いますけど、寄付催促メールのしつこさはちょっと嫌ですね……。

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

[編集者: すずき]
[更新: 2020年 8月 8日 14:24]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

車検

車検証と検査証票(フロントガラスに貼るステッカー)が届きました。

いつもならディーラーさんに 1週間くらい預けるので、車検証もそのときに付いてきます。今回は奥さんの通院の送り迎えに車が必要で、スバルのディーラーさんに無理を言って土日月の 3日で車検を終わらせてもらいました。

車検の検査自体は終わっても、車検証の発行が間に合わなかったので、後から郵送されてきた、ってことです。

検査内容

リアのロアアームブッシュが破損していたので、交換になった程度で、他は特に何もありませんでした。部品の在庫があって良かったです。

[編集者: すずき]
[更新: 2020年 8月 8日 14:35]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

エナジードリンクとお国柄

マクドナルドが各国で味付けが違うのは有名ですが、エナジードリンクにもお国柄があって USA 版の Monster Energy はタウリンあり、日本版はタウリンなしの製品が販売されています。これは Red Bull も同様です。ただしエナジードリンクの場合、味付けの問題ではなく法律の問題です。

日本では、タウリンを入れると医薬部外品になり、製造業者+販売業者の厚労省の許可、商品ごとに承認が必要になります。Monster Energy 製造、販売元のアサヒ飲料は清涼飲料水製造メーカーなので、医薬部外品製造の設備は持っていないでしょう。たぶん。

実はヒトはタウリンを外部から摂取しなくても、体内で生合成できますから、生合成の原料となる物質を入れれば良いじゃない?と思うかもしれませんが、そんな甘くありません。厚生労働省の告示(リンク)(※)を見るとわかる通り、タウリンの主要な合成経路「L-メチオニン → L-システイン → タウリン」のいずれも医薬部外品扱いで清涼飲料水には添加できません。

L-メチオニンは必須アミノ酸なので生合成不可能、すなわち他の成分をいくら入れても代用になりません。必須アミノ酸は全て医薬部外品として指定されている辺り、良くできた法律です。

薬事法の目的「保健衛生の向上」を見る限り、必須アミノ酸を規制する意味ある……?という気になりますけど、一方で「医薬品、医療機器及び再生医療等製品の研究開発の促進」という目的もあります。苦労して薬効成分を見つけた製薬会社、高価な製造設備を入れているメーカーの権益を保護してあげるから、これからも医療品の研究開発を頑張ってくれたまえ〜!という法律なんですね。なるほどねえ。

(※)厚生省告示第百九十四号 - 都道府県知事の承認に係る医薬部外品という文書名です。

[編集者: すずき]
[更新: 2020年 8月 15日 18:10]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

CPAP の効果

SpO2(血中酸素飽和度)を測りながら CPAP を付けて寝たところ、途中で寝苦しくて起きてしまい、CPAP を外して二度寝しました。このときの SpO2 の変化がなかなか面白いです。


CPAP あり〜外すまでの 1時間


CPAP なしの最初の 1時間


そのあとの 1時間

CPAP 外すと SpO2 は明らかに悪化(2枚目)するかと思えば、CPAP ない方がマシ(3枚目)な時間もあります。CPAP なしで寝た場合も何度か測っていますが、寝た直後は SpO2 が悪化しますが、しばらく経つと悪化しなくなることが多いです。

睡眠のサイクルとか、寝ている姿勢とか、何かしら呼吸が止まる原因があるはずなんですが、寝ている自分には全くわからないし、突き止めるのが難しいですね……。

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

[編集者: すずき]
[更新: 2020年 8月 15日 16:55]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link permalink

link 編集する

サラウンドヘッドフォンシステム

先日(2020年 8月 3日の日記参照)購入したサラウンドヘッドフォンシステム SONY MDR-HW700DS ですが、このような仕様みたいです。

  • スタンバイ(電源LEDがオレンジ):入力側の HDMI をパススルー
  • 電源OFF(電源LEDが消灯):入力側の HDMI をカット

今日の朝、何かの拍子に電源 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 固定で使うことにします……。

[編集者: すずき]
[更新: 2020年 8月 15日 19:25]

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



こんてんつ

open/close wiki
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報