コグノスケ

未来から過去へ表示(*) link

過去から未来へ表示

もっと前

2024年10月30日 >>> 2024年10月17日

もっと後

ONKYOからM-AUDIOのUSB DACへ

目次: PC

かれこれ10年以上（2013年3月16日の日記参照）活躍してくれたONKYO SE-U33GXV2ですが、いよいよ調子が悪くなってきたようです。しばらく放っておくと音が出なくなってしまいます。

Windows 11のアップデート直後から発生するようになったので、Windows 11のせいである可能性もゼロではありません。が、同様の不具合に言及している人が見当たらないところを見ると、USB DACが故障した可能性の方が高いでしょう。

次のUSB DACはM-AUDIO M-Track Solo（メーカーのサイト）にしました。実はしばらく前に購入していたのに使わずに積んだままでした。活躍の場ができて良かったです。

M-Track Solo

入力が2系統（XLR/6.3mmステレオコンボプラグ: マイク/Line、6.3mmステレオプラグ: ギターなど/Line）、出力が2系統（RCAプラグ: スピーカー、3.5mmミニプラグ: ヘッドフォン）あります。ありがたいですね。

ボリュームつまみは大きくて見やすく、筐体の上部に付いています。私のように目線より下（机やPC筐体の上など）に置く人には、操作しやすくて良いです。一方でラックに入れて使う人にはやや使いづらいかもしれません。

動作も問題ないですね、変なノイズやおかしな音はしません。音質は良いんじゃないでしょうか、私の耳では細かいことは良くわかりませんけども……。

編集者:すずき(2024/10/25 02:35)

コメント一覧

コメントはありません。

この記事にコメントする

OpenPilotを調べる - プロセス間通信msgqの仕組み

目次: OpenPilot

最近はOSSの運転支援ソフトウェアOpenPilotのコードを見ています。今日はOpenPilotのプロセス間通信について調べます。

OpenPilotは複数のプロセスが共有メモリを通じてデータを送受信しています。データ送受信のモデルはPublisher/Subscriberモデルを採用していて、1つの通信チャネルについて1つだけPublisherがいてデータ送信役を担い、複数のSubscriberがいてデータ受信役を担います。Client/Serverモデルとは異なりデータはPublisherからSubscriberへの一方通行で、SubscriberからPublisherに送ることはできません。

Publisher/Subscriberの仕組みの名前が見当たらなかったので、関連するコードのディレクトリ（openpilot/cereal）からcerealと呼びます。画像用のPublisher/Subscriberの仕組みだけ特別にVisionIpc（openpilot/msgq/msgq/visionipc）と名前が付いていてcerealと実装が異なりますが、背後にあるデータ送受信の仕組みmsgq（openpilot/msgq）は共通です。

実装箇所

今回の着目点はmsgqですから、cerealとVisionIpcの違いは扱いません。簡単に双方ともmsgqを使う経路がある説明だけに留めます。

まずcerealです。cerealはPython用およびC++用のクラス定義を行っています。Publisher用がPubMaster、Subscriber用がSubMasterです。PythonもC++も同じクラス名で、クラス定義、実装箇所は下記のとおりです。

Python用: openpilot/cereal/messaging/__init__.py
C++用: openpilot/cereal/messaging/socketmaster.cc

背後のデータ送受信の仕組みはopenpilot/msgq/msgq/msgq.ccにあります。関数がプレフィクスmsgq_から始まるので見分けやすいです。cerealのPubMaster/SubMasterからmsgqのコードに至る経路は下記のとおりです。

cerealの実行経路の概要

PubMaster::PubMaster()
  PubSocket::create()
    MSGQPubSocket::connect()
      msgq_new_queue()

SubMaster::SubMaster()
  SubSocket::create()
    MSGQSubSocket::connect()
      msgq_new_queue()

次にVisionIpcのServer/Clientからmsgqのコードに至る経路は下記のとおりです。コンポーネントによって呼び出し元は違うので、例としてPublisher側はreplayのCameraServer、Subscriber側はuiのCameraWidgetからの経路を挙げます。

VisionIpcの実行経路の概要

CameraServer::startVipcServer()
  VisionIpcServer::create_buffers_with_sizes()
    PubSocket::create()
      MSGQPubSocket::connect()
        msgq_new_queue()

CameraWidget::vipcThread()
  VisionIpcClient::VisionIpcClient()
    SubSocket::create()
      MSGQSubSocket::connect()
        msgq_new_queue()

経路は多少違うもののcerealもVisionIpcも両方ともmsgqに行き着きます。ただしcerealはmsgq以外の経路（ZMQ）が選択可能で、ZMQを選択した場合は上記と異なる実行経路となります。

msgqのデータ共有方法

ファイルの共有メモリマップをお互いのプロセスから読み書きしてデータ共有します。msgq_new_queue()にて/dev/shmにあるtmpfsファイルシステム（メモリ上にファイルシステムを作る仕組み）上に1つの通信チャネルごとに1つファイルを作成します。1つのファイルをPublisherとSubscriberが共有メモリマッピングするので、お互いに同じファイルのデータが見えます。Publisherがメモリマップ経由でファイルを書き換えたらSubscriber全員に変更が見える仕組みです。

通常、ファイルの共有メモリマップに書き込んだ内容を他のプロセスに可視化するときはmsync()を呼ぶ必要があります。しかしmsgqの実装はtmpfs決め打ちというか、msync()の手間を惜しんだのか、atomicアクセスもしくはメモリバリア__sync_synchronize()だけで済ませています。うーん？これでも動くんだ……？

msgqの変更可視化の実装例（Publisher側のsend）


// openpilot/msgq_repo/msgq/msgq.cc

int msgq_msg_send(msgq_msg_t * msg, msgq_queue_t *q){
  //...

  //★★q->dataは共有メモリマップへのポインタ★★
  char *p = q->data + write_pointer; // add base offset

  //...

  // Write size tag
  //★★atomicアクセス★★
  std::atomic<int64_t> *size_p = reinterpret_cast<std::atomic<int64_t>*>(p);
  *size_p = msg->size;

  // Copy data
  //★★memcpy + メモリバリア★★
  memcpy(p + sizeof(int64_t), msg->data, msg->size);
  __sync_synchronize();

ファイル内のデータは下記のようにヘッダ領域とデータ領域の2領域からなります。各プロセスにはmsgq_queue_t構造体が確保され、ヘッダ領域とデータ領域へのポインタを保持します。

msgqのデータ共有用ファイルの構造

データ領域のサイズはDEFAULT_SEGMENT_SIZE（10MiB）固定です。Subscriber数の最大数はread_pointers[]などの配列長で決まります、現状だとNUM_READERS（15）固定です。なぜ16じゃなくて15なのか？理由が良くわかりません。特に理由は書いていませんでした。

msgqのデータ構造体（一部）


// openpilot/msgq_repo/msgq/msgq.h

#define DEFAULT_SEGMENT_SIZE (10 * 1024 * 1024)
#define NUM_READERS 15
#define ALIGN(n) ((n + (8 - 1)) & -8)

struct  msgq_header_t {
  uint64_t num_readers;
  uint64_t write_pointer;
  uint64_t write_uid;
  uint64_t read_pointers[NUM_READERS];
  uint64_t read_valids[NUM_READERS];
  uint64_t read_uids[NUM_READERS];
};

struct msgq_queue_t {
  std::atomic<uint64_t> *num_readers;
  std::atomic<uint64_t> *write_pointer;
  std::atomic<uint64_t> *write_uid;
  std::atomic<uint64_t> *read_pointers[NUM_READERS];
  std::atomic<uint64_t> *read_valids[NUM_READERS];
  std::atomic<uint64_t> *read_uids[NUM_READERS];
  char * mmap_p;
  char * data;
  size_t size;
  int reader_id;
  uint64_t read_uid_local;
  uint64_t write_uid_local;

  bool read_conflate;
  std::string endpoint;
};

PublisherとSubscriberが1プロセスずついるときはこんな感じです。msgq_header_tの実体は1つで、各プロセスのmsgq_queue_tがmsgq_header_tとデータ領域へのポインタを保持します。

PublisherとSubscriber間のtmpファイル共有

データ領域はPublisherが書き手、Subscriberが読み手のリングバッファとして機能します。つまりPublisherはデータ領域に送信したいデータを書いてwrite_pointerを進め、Subscriberはデータ領域からデータを読み取ってread_pointerを進めます。

編集者:すずき(2024/10/25 02:18)

コメント一覧

コメントはありません。

この記事にコメントする

2024年10月20日

permalink

編集する

ゲームを買ったら遊びましょう2

目次: ゲーム

前回の振り返り（2022年5月13日の日記参照）から2年半経ちました。所持しているゲームのリストを見るとほとんど変わっていなくて、最近ゲームしてないことが良く表れてます。特に続編系は情熱をもって遊べていないですね。小規模ゲームはいくつかクリアしました。

Skylines 2: 順当な続編である印象を受けますね、システムは大体一緒です。リリース直後はゲームバランスが変で遊ばなくなりました。そのうち改善されるでしょう。
スプラ3: 初めから超絶ボコボコにされてやる気ゼロになりました。下手くそには辛い。
Wizardry外伝: 初期のWizardry目指して作った感じですかね？昔のWiz好きなら面白いと思います。追加シナリオ1個（戦闘の監獄、Prisoners of the Battles）をクリアしましたが、基本シナリオ5個全部クリアする元気はありませんでした。
熱血硬派くにおくん外伝: くにおくんシリーズを裏切らない、たくさん出てくる敵をボコボコにしていくシステムで面白いです。が、私はアクションが基本的に好きではなくて、あまり続きませんでした。
8番出口: 地下鉄の通路を思わせる道に起きた異変を察知しながら脱出を試みるゲームです。短いながら面白かったです。アイデアの勝利ですね。