そういえは結構前に Google Analytics は止めていたようだ。いつ止めたかわからない。まったく見てもいないのにサイトレスポンスを下げるのでさくっと消したようだ。

Adsense はわずかながらレンタルサーバ代になるぐらいの収益があり、サイトレスポンスへの悪影響は気になっていたものの、貧乏性すぎて消すのにずいぶん躊躇していた。しかし最近ほかのサイトの Ads by Google と書かれた広告で、かなりひどいのを見かけて、もうダメだと思った。

Adsense ではひどい広告はあまり出ないと思っていたが、そんなことはないみたい。

  1. トップ
  2. tech
  3. このサイトの Google Adsense 止めた

https://cho45.stfuawsc.com/metronome/

あいかわらず自分で書いたメトロノーム実装を使っているが、フットスイッチで操作できればなという気持ちになったので、MIDI対応をした。

https://github.com/cho45/metronome/commit/49f94e836e388c5e61c147a8ea5a86ccbf33312a#diff-ed3ee7e0beea2498ff3b8ca85973d122fc6fa3d585d62b5807ec034d0cf076b3R616

Web MIDI API はオリジンごとに一括で許可/不許可を与え、一度許可すると次からは prompt なしで接続できるようだ。なので最初の一度だけセットアップ(許可)を行うと次からはページをロードするだけでMIDIメッセージは受け取れる状態になる。


細かい機能 (3連の裏をとれるようにするサポートとか) をちまちま追加したりしていて、こういう小さいツールは自分で作る喜びがあっていいなと思う。

  1. トップ
  2. tech
  3. JSで書いたメトロノームの MIDI 対応

HOTONE AMPERO II STOMP - HOTONE

HOTONE

5.0 / 5.0


競合としては BOSS GT-1000CORE とか、LINE6 HX Stomp あたりが値段が近い。

どう選んだか HOTONE vs BOSS vs LINE6

私見

    • Ampero は HOTONE のブランド (中国)
    • BOSS は Rolandのブランド (日本)
    • LINE6はYAMAHAのブランド (元々はアメリカの会社)
  • 基本的な音の傾向的にレンジの広さは GT-1000CORE > Ampero > HX Stomp
    • レンジが広いほどCDっぽく聞こえる?
    • 狭いほど生っぽく聞こえる?
  • 操作性 Ampero > (GT-1000CORE or HX Stomp)
    • Ampero はカラーのタッチパネル
  • 筐体デザインの好みは Ampero >= HX Stomp > GT-1000CORE
    • BOSS はなんか全体的にフォントが好きじゃない……
    • HX Stomp はかっこいい
  • Amperoはこれらのなかでは唯一USB接続がType-C。(USB2.0)
    • とはいえ電源供給はできず、通信ポートでしかない

買ってよかったところ

  • PCのソフトウェアが割と良い
    • 起動しっぱなしで良い。本体を電源オフにしたらPC側も Disconnected になるだけで、そのまま本体をオンにしたら勝手にPC側にも同期する。ずっとPCに接続してるなら屈んで本体を操作する必要はない。
  • USB入力が多様
    • ドライ音と出力音などを同時に録音できる
  • ステレオのエフェクトがとてもいい
    • 不自然さを感じにくい。とはいえときどき定位が不安定

買って気になったところ

  • スイッチのラグ
    • スイッチを押したタイミングではなく、離したタイミングで発火する。この機種に限らず、マルチエフェクターなら普通の挙動ではあるが、スイッチに長押しもアサインされているので、トリガーのタイミングがアナログエフェクターとそもそも違う。
    • ちなみに外部スイッチを接続した場合、このスイッチを押したタイミングで発火する。
  • 発熱
    • 電源オン状態で本体は40-50℃ぐらいになる。ずっとつけっぱなしにしておくには躊躇する温度。
  • ノイズゲートはいまいちかも?
    • 閾値をちゃんと設定しないといけない。どのゲートも小信号になったとき微妙にオン・オフが振動する。
  • 電源でかい
    • 18V 2A、センターマイナスのアダプタが付属するが、これがでかい。他の方法で給電したくなる。ただ入力電圧が9V〜18Vと広いので他の方法で給電しやすい。

ファームウェア

  • v1.2.0 が入っていた
  • v2.0.0 へアップデートするが再起動後、起動スプラッシュでフリーズ。なんどか再起動してもダメ。
  • → 再度 v2.0.0 でアップデートかけてみる → ダメ
  • v1.3.0 にアップデートをかけてみる → いけた。
  • → この状態でファクトリーリセット
  • →再度 v2.0.0 にアップデート → いけた

http://community.hotoneaudio.com/forum/discussionDetail?id=602

ほか

ZOOM FP02M は使えない

全く使えなくはないが3段階ぐらいしか可変しないので実質は使えない。
Ampero Press は 10kΩリニアカーブらしいが、FP02M は 100kΩのAカーブっぽい?

一応、本体不具合も疑って、手元の10kΩ Bカーブの普通のpotで確認したが、それだと問題なかったので、抵抗値かカーブかで相性がありそう。

電源

18V 2A、センターマイナスのアダプタが付属するけどやたらでかい。基本的に USB PD で供給するようになんとかしている。

直接供給

Hotone Ampero II STOMP は入力電圧が 9〜18Vなので、とりあえず Type-C Power Delivery のアダプタから15Vをひっぱってきて使ってみていた。特に問題はなく使えた。こうしとけば、PD 15V出せるモバイルバッテリー使えばバッテリー駆動できる。

これをするのに必要なのは

  • 15V 2A 出せるアダプタ: https://www.amazon.co.jp/gp/product/B0BJ6BB44D/
  • USB PD トリガーケーブル 15V。トリガーケーブルというのはPDのネゴシエーションだけやって特定の電圧を出してくれるケーブルのこと。これでアダプタの出力を15Vにする
  • DCコネクタ: エフェクタ界隈はセンターマイナスとかいう常識からすると異常な世界なので再配線が必要。

なおセンターマイナス問題はかなりうざいので、ブリッジダイオードで全波整流して極性を統一するケーブルを別途予備につくっておいている。

パワーサプライ

他のペダルと同時に使う場合、電源が一本化されていたほうが楽なので、パワーサプライを使うほうがよい。
VITAL AUDIO POWER CARRIER VA-05 MkII というパワーサプライを使っている。全ポートがアイソレート(絶縁)されている、つまりトランスが入っているタイプ。

ただ、供給電流が 9V 500mA と Ampero II STOMP が要求する 9V 800mA には足りないので、2ポートを並列にしている。絶縁電源なのでただの並列でもだいたい大丈夫なはず。

このパワーサプライは入力が 12V 2A なので、12V で PD をトリガーできる基板を利用している。12V は PD では若干特殊なので、対応していない充電器が多くてイマイチ。15V で供給したくなるが、内部の入力電解コンデンサの耐圧が16Vと余裕がなさすぎるので、素直に12Vを供給させている。

MIDI

PCアプリとの通信は MIDI の SysEx で行われているようだ。

本体の DIN の MIDI IN に入ってくる MIDI メッセージは USB にもスルーしてくる。MIDI フットスイッチがある場合、Ampero に接続しておけば、Ampero の USB 接続からその MIDI メッセージも受信できる。

Ampero Control は Bluetooth / USB / DIN で MIDI メッセージを出せるフットスイッチ。かなり汎用性が高い割に価格はこの手のものだと安い (14000~18000ぐらい)。ただしアプリがないと全く設定ができない。

スイッチの挙動

4つのモードがある

  • Single: スイッチを離したときにメッセージ送信
  • Toggle: A Group / B Group を交互。スイッチを離したときにメッセージを送信
  • Momentary: スイッチを押したときに A Group、離したときに B Group を送信
  • Hold: 一定間隔でメッセージを送信

押した瞬間にメッセージを送信

注意書きとして「Ampero Control のスイッチング機能は、踏んだ(押した)フットスイッチを離した時にメッセージ信号を発信します。他社製品に見られるスイッチング動作機能の設定変更はできません。」と書いてあるが、これは微妙に誤解を生むというか、実際は「押したときにメッセージを送信する」という挙動は限定的に実現できる。

というのも Momentary というモードだと、スイッチを「押したとき (A Group)」と「離したとき (B Group)」でメッセージを送信できるため、Momentary モードで A Group にだけメッセージを設定すると「スイッチを押したときにメッセージ送信」という挙動になる。Single というモードは実質、Momentary の B Group のみに登録された状態なので存在意義は謎

ただし Toggle に関しては離したときにメッセージ送信という挙動が変更できない。ただ、Toggle はフットスイッチ側に状態を持つ (モーダル) という側面があるので可能な限り使わないほうが良いと思う。

その他メモ

  • Bluetooth は BLE で設定用とおもわれる特殊なサービスを公開している。
  • アプリは Flutter 製

結論からいうと

ここでいう「微妙な音ずれ」はサンプルレート48kHzで、1分あたり18サンプル(=0.4ms)のもので、普通は気になるものではない。

これは原理的になくせないずれである。

経緯

OBSで複数のUSBオーディオデバイスからの音声をマルチトラック化して録画データにくっつけている。アナログで同じ音声を入力している別々のデバイスの2つのトラックの音を細かくあわせてみると、デバイス間で徐々に広がる遅延があることに気付いた。あまり大きい量ではないが、気持ち悪いので一旦調べてみることにした。(詳しい人はこの時点でそりゃダメじゃんと思うだろうが……)

だいたい1分で18サンプル(=0.4ms)ぐらい進んでいる。2分ならもっとすすむ (数えるのが面倒だけどだいたい倍ぐらい)。

追試として、同じアナログ入力をしている2つのインターフェイスを同時にOBSで録音して、録画開始直後に同期をとり、その後の1時間ぐらい波形のずれを見た。メトロノームを鳴らして音声入力にした。

  • 26分後ぐらいに急に3フレームぐらい前にずれた
  • 35分後ぐらいに1フレームぐらい後ろにずれた

前にずれる・後ろにずれるということが起こる。ずっと一定でずれていくわけではない。実時間録音してるのだからどこかで補正(音トビ)しないとおかしいのは当然ではあるが……

クロック誤差を考える

何も考えず、サンプルレートを変えたり、設定を変えたり ASIO にしてみたり、いろいろ試行錯誤してみたがこの現象は消えなかった。最終的にクロック誤差ではないかと思いはじめた。

クロック誤差が通常の水晶を想定して±50ppm なら、48kHz のサンプルレートとしても、実際は±2.4Hz (48e3 * 50e-6) となり、最悪 (48002.4Hz vs 47997.6Hz) で考えると1秒あたり4.8サンプルずつずれていくことになる。

1分で18サンプルなら、逆算するとデバイス間に0.3Hz (18/60) 差があることになる。(0.3 / 48e3 * 1e6=6.25ppm) これは水晶の精度から考えると少ない誤差といえる。

クロックソースはホストPCとオーディオデバイスどちらもあり、完全に同期していない。リアルタイム処理だと、原理的にサンプルパーフェクトで処理することはできない。実時間に対してずれていってしまう (PCやデバイスのクロックの1秒と実時間の真の1秒の誤差) から仕方ない。

デバイスクロックがPCクロックより早い場合、PCからすれば余計にデータが送られてくるので、少しずつデータが伸びていく (その音声はPCから見れば遅れていく)。伸びていくといっても実装によって限界が生じる(バッファオーバーラン)のでそのうち音飛びする。

逆にデバイスがPCよりクロックが遅い場合、PCからすればデータが足りない(バッファアンダーラン)ので一定時間ごとに音飛びする。

複数のオーディオデバイスがある場合、この現象がそれぞれのデバイスに対して生じる。

USB Audio の仕様

https://www.edn.com/fundamentals-of-usb-audio/
https://learn.microsoft.com/ja-jp/windows-hardware/drivers/audio/usb-2-0-audio-drivers

USB Audio 的にはクロックソースの選択や、クロックの同期について部分的に書かれてはいるが、ずれた結果どうすべきかは書いてない。そもそもリアルタイムの非同期転送だと送りっぱなしで再送とかもないので実は伝送エラーが起きてもそのままである (訂正されたりしない)。

アンダーランやオーバーランをどうすべきかはアプリケーションの用途によるだろうからそういうもんかとは思う (配信ソフトなら音ズレが少ないほうが好ましいが、録音ソフトなら音トビが少ないほうが好ましい、というような)

OBSの実装に関するメモ

OBS のサンプリングレート

OBS は設定の「音声」にあるサンプリングレート (48k または 44.1k) が内部ではプライマリーとなっている。オーディオソースのサンプリングレートがこれと違う場合は常にリサンプリングされて統一される。ビット深度はOBS内部では常に float (=float 32bit) で処理されている。

(出力ビット深度は出力の話なのでエンコーダ設定にある)

サンプルが余るような場合どうなるか

OBS自体はオーディオ信号がきた時刻(PC内のカウンタ)を基準にサンプルを整列させていく実装になっているように見える。リサンプリングして余計なサンプルがでてきた場合、あとから生成されたサンプルで上書きされている。

https://github.com/obsproject/obs-studio/blob/ba4f17e1143dd769f55bce6b1595c6704aa7a44d/libobs/obs-source.c#L1471-L1489

つまりOBS的には、基準クロックがPC内のカウンタということになる。PCのクロックはそれほど高精度ではないという問題がある。(PC内は温度変化が激しい。TCXO積むような意味は普通ない)

メモ: OBS の「デバイスのタイムスタンプを使用する」ってなんなのか

この設定は Windows のみ。

  • オンの場合、OBS 内にサンプルが届いたタイミングでカウンタを読む
  • オフの場合、Windows 側で (ドライバ or WASAPIが) サンプルをコピーする直前にカウンタを読む

結論からいえばデバイスドライバの実装が壊れていない限りオフにする必要はない。

UseDeviceTiming https://github.com/obsproject/obs-studio/blob/4b138f674f982c1b85487ff0cf6e3cabd27a76b4/plugins/win-wasapi/win-wasapi.cpp#L1142-L1148 というフラグ

UseDeviceTiming なら
https://learn.microsoft.com/en-us/windows/win32/api/audioclient/nf-audioclient-iaudiocaptureclient-getbuffer でとれる pu64QPCPosition (これはWASAPI )

パフォーマンスカウンタ (OS内の高精度でプロセッサ共通のカウンタ) から求められるタイムスタンプを算出して使う

UseDeviceTiming なら、この処理時点の os_gettime_ns を使う。os_gettime_ns は実際のところ https://github.com/obsproject/obs-studio/blob/4b138f674f982c1b85487ff0cf6e3cabd27a76b4/libobs/util/platform-windows.c#L481 QueryPerformanceCounter を使っている。

https://github.com/obsproject/obs-studio/blob/4953c5d517c899517a49360463ad7b70c91dea14/plugins/win-wasapi/win-wasapi.cpp#L1206-L1258 ProcessCaptureData

asio plugin は、ASIO にパフォーマンスカウンタをどうこうする仕組みはないので、コールバック時点の os_gettime_ns を使う。https://github.com/Andersama/obs-asio/blob/asio-juce/src/asio-input.cpp#L317


https://docs.obsproject.com/backend-design#general-audio-pipeline-overview
https://github.com/obsproject/obs-studio/blob/2c58185af3c85f4e594a4c067c9dfe5fa4b5b0a9/libobs/obs-source.c#L1203 MAX_TS_VAR = 2000000000ns = 2秒
ts の処理、sync_offset の追加

サンプリングレートが違うと音がずれる?

OBSの実装上、リサンプリングが入るので、サンプリングレートがオーディオソースごとに異なるからといって音がずれていくということはない。言いかえるとサンプリングレートが原因で音ずれるというのはOBS内では起こらない。

動画と音は、なぜずれるか

動画と音の場合、バッファサイズの違いが問題になる。動画はフレームを飛ばしたり重複させて時間調整しても気付きにくい。音声は動画(60Hz)に対して(48kHz)とケタ違いの分解能を持っており、数サンプル飛んでだけでもプチという高周波音で気付いてしまう。

連続して録音していく場合、オーディオインターフェイス側のクロックがホストより早いとサンプルが余り、徐々に遅れていく。余ったサンプルがどうなるかはインターフェイス側のバッファの実装による。

オーディオインターフェイス側のクロックがホストより遅いと、サンプル数がPCの想定より足りないので、定期的に音が途切れて同期する。バッファを超えて長い時間で「ずれ」はしない。

究極的にずれないようにするためには音声クロック(マスタークロック)に同期した動画のフレーム調整が必要になる。

Windows の時刻精度

ハードウェアクロックが複数ある場合補正して精度を高めると書いてある。どの程度の精度があるかはわからない。
https://learn.microsoft.com/ja-jp/windows/win32/sysinfo/acquiring-high-resolution-time-stamps#absolute-clocks-and-difference-clocks

  1. トップ
  2. tech
  3. クロックによるOBSの微妙な音ずれはなおせない