← 2025-12-16 の一覧へ戻るホーム
Fix HDMI-CEC weirdness with a Raspberry Pi and a $7 cable

2025/12/16 6:37

Fix HDMI-CEC weirdness with a Raspberry Pi and a $7 cable

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

概要：
Samsung S95B TV（論理アドレス 0x00）、Denon AVR‑X1700H（0x05）、Apple TV、PS5、Xbox Series X、Nintendo Switch 2、および 

/dev/cec0
をリッスンする Raspberry Pi 4 が含まれるホームシアター構成で、テレビの入力にのみ切り替えるコンソールが原因となるオーディオルーティング問題を著者は解決します。
Pi（論理アドレス 0x01）から AVR に「System Audio Mode Request」パケット（
15:70:00:00
）を送信することで、受信機は ARC を有効化し、すべてのコンソールオーディオをテレビではなく自身経由でルーティングします。
著者は Python スクリプト 
cec_auto_audio
でこれを実装しており、長時間稼働する 
cec-client -d 8
を起動し、TRAFFIC 行から Active Source イベント（オペコード 0x82）を解析し、以前に Set System Audio Mode（オペコード 0x72）が検出されていない場合に毎回ウェイク時にパケットを送信します。
スクリプトは systemd サービス 
cec_auto_audio.service
としてパッケージ化され、起動時に開始されます。これにより、多層の HomeKit/Eve オートメーションと比べて低レイテンシで軽量な代替手段を提供します。
トラブルシューティングガイドには、スキャン（
echo "scan" | cec-client -s
）、トラフィック監視（
cec-client -m
）、および欠落オペコード（0x82, 0x84, 0x70, 0x72）の良いケースと悪いケースの比較が含まれます。
残るエッジケースとして、コンソールのスタンバイがテレビチューナーを起動させる場合や HomeKit オートメーションがアクティブなソースなしでテレビをオンにする場合などには、追加の状態機械ロジックが必要になる可能性があります。著者はコミュニティメンバーに対し、より広範なトラブルシューティングのために CEC パケットトレースを共有してもらうよう呼びかけています。

本文

これまでの背景

数年間、HDMI‑CEC を「家の精霊」のように扱ってきました。
時には役立つこともあれば、ほぼ変わり者で、完全に理解できていないままです。

私のリビングの構成はシンプルです：

  • Samsung TV（ARC あり、eARC ではありません）
  • Denon AVR‑X1700H をクローゼットに隠し収納
  • Apple TV と数機種のゲーム機をレシーバーへ接続
  • Raspberry Pi 4 が Homebridge の役割も担っている

CEC に関しては、Apple TV は完璧に動作しますが、他のコンソールは CEC を最後の学期で抜けてしまったかのようです。
テレビを起動させ、入力を切り替えた後、Denon はスリープ状態のままで、私は音声出力を手動で切り替える必要があります。

メディアクローゼットの構築は別途記載していますので、配線図と写真が欲しい場合はそちらからご覧ください。

問題点

  • メディアクローゼットで TV への再配線は不可能
  • CEC を無効にすることも現実的ではない（Apple TV は機能し、最頻使用デバイス）

そこで、まずは従来の自動化スタックを検討しました。
HomeKit シーンで「テレビ ON → レシーバー ON」をチェインしたり、Eve Energy プラグでワット数トリガーを設定したりです。
これはある程度機能しますが、追加レイヤーごとに 30 秒以上の遅延が発生しました。

最終的に Homebridge‑CEC‑TV‑Control プラグインへ行きましたが、README を読んでいるうちに「Node → Homebridge → HomeKit」を経由して CEC メッセージを送ることになると悟りました。
Pi はすでにラックに接続されているので、これらのレイヤーを飛ばし 

/dev/cec0
へ直接書き込む方が高速です。

数時間の試行錯誤の末、Pi は HDMI バス上で静かに待機し、コンソールが自分をアナウンスすると、Samsung と Denon が自動的に交換すべき単一コマンドを発信します。

本記事の構成

  1. CEC の小さなメンタルモデルを作る
  2. バスを監視する
  3. Apple TV が正しくやっていることをコピーする
  4. Python でラップする
  5. systemd ユニットとして配備する

HDMI‑CEC 入門

HDMI‑Consumer Electronics Control（CEC）は、HDMI ビデオ/オーディオと並行して走る低帯域幅のサイドチャネルです。
バス上の全機器は論理アドレス（TV は 

0x0
、オーディオシステムは 
0x5
、再生装置は 
0x4/0x8/0xB1
など）と小さなオペコードで通信します。

物理アドレスはトポロジー内の「緯度／経度」参照です。例えば 

3.0.0.0
は「AVR の HDMI 3 入力」を意味します。
CEC は消費者がエレクトロニクスを制御できるように設計されており、健全なシステムでは次のフローになります。

コンソール起動 → 自身をアクティブソースとして宣言
TV が ARC パートナーを検知
誰かが「オーディオシステムになってください」と要求
レシーバー起動 → 大きなスピーカーから音声出力

私のホームシアターでは、Apple TV が関与している場合にのみこのパスが通ります。
コンソールを起動するとテレビは入力を切り替えますが、オーディオは小さな TV スピーカーに留まります。

デバイスの役割

デバイス論理アドレス
TV
0x0
オーディオシステム（Denon AVR‑X1700H）
0x5
再生装置（Apple TV、PS5、Switch 2、Xbox）
0x4
, 
0x8
, 
0xB
ブロードキャスト
0xF

主なオペコード

  • 0x82
    – Active Source
  • 0x84
    – Report Physical Address
  • 0x70
    – System Audio Mode Request
  • 0x72
    – Set System Audio Mode

cec-client
で CEC バスを監視する

Raspberry Pi 4 は 

/dev/cec0
を公開しています。
$7 の micro‑HDMI→HDMI ケーブルを AVR の未使用 HDMI ポートに接続すると、単なる参加者として振る舞います。信号再生や偽装 EDID はありません。

sudo apt update
sudo apt install cec-utils

echo "scan" | cec-client -s

スキャン結果の例（アドレスは省略）：

device #0: TV  address: 0.0.0.0  vendor: Samsung
device #1: Recorder 1  address: 3.3.0.0  vendor: Pulse Eight
device #4: Playback 1  address: 3.1.0.0  vendor: Unknown (Switch 2)
device #5: Audio      address: 3.0.0.0  vendor: Denon
device #8: Playback 2  address: 3.2.0.0  vendor: Apple
device #B: Playback 3  address: 3.6.0.0  vendor: Sony (PS5)

トラフィックを監視するには：

cec-client -d 8   # ログレベル 8（詳細）


TRAFFIC: [...] >> bf:82:36:00
のような行は、論理 
0xB
（PS5）が物理アドレス 
3.6.0.0
を持つ Active Source をブロードキャストしたことを示します。

マジックハンドシェイクの発見

システムをスタンバイにしてログ収集を開始し、Apple TV を起動しました：

8f:82:32:00       # Apple TV (logical 8) → Broadcast: Active Source
...
5f:72:01          # Denon (logical 5) → Broadcast: Set System Audio Mode (on)

Apple TV は自分をアクティブソースとして宣言し、Denon は「システムオーディオモードはオン」と全員に告げます。TV はレシーバーへの出力設定を維持します。

PS5、Xbox、Switch 2 では Active Source は見られましたが 

5f:72:01
はありませんでした。
つまり「コンソール起動後の Set System Audio Mode ブロードキャスト」が欠けているのです。

cec‑o‑matic.com を使って Pi が送信する CEC フレームを作成しました：

15:70:00:00  # TV (1) → Audio (5): System Audio Mode Request


15
= ソース 
0x1
（Recorder 1＝Pi）
70
= オペコード System Audio Mode Request
00:00
= オペランド（TV の物理アドレス 
0.0.0.0
、オーディオ状態 OFF）

このフレームをインタラクティブ 

cec-client
で送ると (
tx 15:70:00:00
) Denon がオンになり、ARC が受信機に固定されます。コンソールと TV のみが電源オンの場合でも同様です。

バスへの過剰な書き込みはやめましょう

数秒ごとに 

cec-client
を呼び出す簡易 Bash ループは遅延が大きく、非効率的です。
代わりに長時間稼働する単一の 
cec-client
プロセスを起動します：

cec-client -d 8

このプロセスはすべての TRAFFIC 行を出力し、標準入力でコマンドを受け付けます（ただし監視モードではない）。
Python スクリプトが橋渡し役となり、stdout がイベントストリーム、stdin が制御チャネルとして機能します。

Python スクリプト

スクリプトのロジックは以下の通りです：

  1. cec-client -d 8
    をサブプロセスとして起動
  2. TRAFFIC 行を解析
  3. 再生装置（論理アドレス 
    0x4
    , 
    0x8
    , 
    0xB
    ）からの Active Source (
    0x82
    ) を検知
  4. 最後に受信した Set System Audio Mode (
    5f:72:01
    ) を追跡し、Apple TV や TV のロジックと競合しないようにする
  5. もし誰も送っていなければ、
    tx 15:70:00:00
    を一度だけ送信

ポイント：

  • デバイス名・ベンダー・物理アドレスをハードコードしていません。
  • 任意の再生装置が Active Source に切り替わった瞬間を「コンソール起動」とみなします。
  • Apple TV / Samsung / Denon が正しく動作した場合は待機し、
    5f:72:01
    を検知すると処理をスキップ。
  • 単一の長時間稼働するプロセスとして実行されます。

GitHub で公開中です：jlian/cec_auto_audio。
systemd サービスにラップして、起動時に自動開始し常駐させました。

アプローチを一般化する手順

  1. Pi を HDMI ポート（micro‑HDMI→HDMI ケーブル）へ接続

  2. バスのベースラインを確認：

    echo "scan" | cec-client -s -d 1

  3. 「良い」シナリオと「悪い」シナリオを 

    cec-client -d 8
    で記録

  4. トレースの差分を取り、欠落しているオペコードを特定

  5. cec‑o‑matic.com で手動送信 (

    tx …
    ) により問題が解決するか確認

  6. 上記マジックパケットを小さなプログラム（Python 等）に組み込み、Pi がバス上で静かに参加

残るエッジケース

ケース可能な対策
コンソールがスタンバイ → TV がアクティブソースになるフレームペアを監視し、短時間後に入力を Apple TV に戻す
日没自動化で「テレビオンだがアクティブソースなし」「TV ON, Denon スリープ, アクティブソース無し」を検知し、Apple TV とレシーバーの両方を起動

「最近最も頻繁にアクティブだったデバイス」を追跡する状態機械を作れば、バスが静寂になったときや TV が自ら切り替えた場合に Apple TV へフォールバックできます。

結論

Apple TV はそのまま動作し続けます。
PS5、Xbox、Switch 2 を起動すると Pi が Denon を半秒以内に呼び込み、音声はレシーバーに固定されます。

Pi はクローゼットで「やや高度なリモコン」として黙って待機しています。
他の HDMI‑CEC の悩みがある場合は、このテクニックを応用してください：欠落したパケットをキャプチャし、Pi から送信し、小さな Python スクリプト + systemd で自動化すれば解決できます。

同じ日のほかのニュース

一覧に戻る →

2025/12/11 8:54

Nature's many attempts to evolve a Nostr

## Japanese Translation: **要約** 人気のあるアプリケーションの普遍的な設計は、ユーザーのデータと暗号鍵を所有する単一クラウドサーバーに集中しています（「あなたの鍵がないなら、あなたのデータではない」）。この中央集権化は封建制や寡占構造を生み出します。サーバーは橋を上げてユーザーを切り離す城のような存在です。フェデレーション（例：Mastodon、Matrix）はサーバー間で通信できるようにしますが、鍵とデータは依然としてサーバーの管理下にあり、ネットワーク理論はそのようなフェデレートシステムがスケールフリー分布へ収束し、支配的なハブを生み出すと予測しています。これはGmail/ProtonMail のメール寡占や Facebook Threads の ActivityPub ノードが Fediverse を支配する現象として観察されています。 セルフホスティングは居住IPの禁止やインフラコストにより多くのユーザーが個人サーバーから離れるため、非実用的になります。ピアツーピアネットワークはユーザー所有鍵を提供しますが、拡張性、信頼できないノード、スーパーpeer の中央集権化、複雑な最終的一致メカニズム、および長い多ホップルーティング遅延に悩まされます。 Nostr プロトコルは「リレーモデル」を提案します。単純で信頼できないリレーは署名されたメッセージを転送するだけで、相互通信しません。これにより \(N^2\) スケーリング問題を回避します。ユーザーは数個（通常 2–10）のリレーユーザーに購読し、自分のデータと鍵を完全に制御でき、リレーが失敗または停止した場合でも信頼性高く離脱できます。広く採用されれば、これはユーザーに真の所有権と単一点障害への耐久性を与え、中央集権サーバーに依存する企業に対し、よりユーザー中心で分散型アーキテクチャとの競争を強いるでしょう。これにより、ソーシャルメディアやメッセージングは真の分散モデルへと再構築される可能性があります。

2025/12/12 15:47

“Are you the one?” is free money

## 日本語訳: --- ## 要約 この記事は、番組「Are You the One?」の参加者が数学モデルを用いて、最終エピソード前にほぼ確実に全ての正しいカップルを推測できる方法を説明しています。戦略的にトゥルーブースとエピソード終了時のマッチアップデータを活用することで達成されます。 - **ゲーム設定**：10人の男性と10人の女性が、色でのみ明らかになる10組の完璧なペアに分けられます。参加者はすべてのペアを正しく推測し、100万ドルを獲得します。 - **情報源**： - *トゥルーブース* は特定のペアが成立しているかどうか（バイナリ結果）を確認します。 - *エピソードマッチアップ* はそのラウンドで正しいペアの総数のみを明らかにします。 「ブラックアウト」エピソード（0件マッチ）は、そのラウンド内のすべてのペアについて否定的な情報を提供し、複数のトゥルーブースと同等の効果があります。 - **モデル**：著者は OR‑Tools の最適化フレームワークを構築し、シーズン開始時に約400万件の有効マッチング（≈4 百万）を追跡し、各イベント後に更新します。シーズン1ではエピソード8でモデルが「解読」されました。 - **情報理論**：各イベントは約1〜1.6ビットの情報量を提供します。シミュレーションでは ~1.23 bits/イベント、実際の番組データでは ~1.39 bits/イベント、最適戦略で最大 1.59 bits/イベントが得られます。全検索空間は約22ビット（10!）を必要とするため、完璧な戦略には平均して約1.1 bits/イベントが十分です。 - **結果**： - ランダムペアリングでは、カップル数に関係なく平均正解スコアは約1になります。 - 100シーズンのランダムシミュレーションでモデルを使用した成功率は74％でしたが、情報理論戦略では98％に上昇します。 - 実際の番組データ（7シーズン）では71％の成功率と約1.39 bits/イベントとなり、純粋なランダムよりわずかに優れていますが、理論的最適値にはまだ届きません。 - **今後の作業**：著者はインタラクティブなウェブツールを開発予定で、ユーザーが異なる戦略を試し、必要な情報ビット数を確認し、実際のデータとパフォーマンスを比較できるようにします。 **影響** 本研究は参加者やプロデューサーに対して効率的な質問設計のための具体的なアルゴリズムフレームワークを提供し、エンターテインメントにおける組合せ最適化とベイズ推論の実用例を示すとともに、研究者にリアルワールドケーススタディとしてさらなる探求の機会を与えます。

2025/12/16 9:34

Ideas Aren't Getting Harder to Find

## Japanese Translation: ``` ## Summary 最近の研究は、先進国における生産性成長の長期的な鈍化が、新しいアイデアの不足よりも、市場メカニズムが資源を効率的に配分できない弱さによるものだと示唆しています。 Bloom et al. (2020) は、研究者一人当たりの研究生産性低下（彼らの式 *Productivity = Research × Researchers* から導かれる）が鈍化を説明すると主張しますが、この見解は商業化障壁を無視しています。モーアズ・ロー（Moore’s Law）のデータは、年間35 %のチップ密度成長を維持するために半導体研究開発努力を18倍増やす必要があり（約7 %の研究生産性低下）、農業収量は年1.5 %で上昇しながらもR&D努力が6–24倍増加したことを示しており、イノベーションに対する限界報酬が減少していることを示しています。 Fort et al. (2024) は企業レベルの特許データを用いて、1977年以降R&D当たりの特許数が50 %増加し、突破的な特許当たりの費用は3倍になったことを示しています。しかしながら、典型的な特許の市場価値は時間とともに低下しており、イノベーションの商業的報酬が減少したことを反映しています。 Decker et al. は、生産性の低い企業が市場シェアを獲得していることを発見し、配分効率の低下を示唆しています。一方、Akcigit & Ates はこの減少を主にリーダー企業に追いつけない遅れた企業の失敗に起因すると述べており、これは市場権力や規制障壁による可能性があります。 この記事は、アイデアが豊富であると仮定して研究資金を拡大する政策から、競争を強化しイノベーティブ企業への報奨を促進する規制インセンティブの改革へシフトすべきだと主張しています。こうした変更は、企業がR&Dを予算化する方法、特許評価、業界の競争ダイナミクスに影響し、最終的には賃金成長と経済繁栄にまで波及する可能性があります。 ``` **Key takeaways:** - 改良された要約は、Bloom の式、モーアズ・ローおよび農業の証拠、Fort が示した R&D 当たりの特許数に関する定量的発見、および Akcigit & Ates が遅れた企業を説明した点を明確に引用しています。 - 直接的な要点で言及されていない推測的な将来政策案は除外されています。 ```

Fix HDMI-CEC weirdness with a Raspberry Pi and a $7 cable | そっか～ニュース