RetroArchの音がバリバリ・プチプチ鳴る問題を解決した話｜PC-98(np2kai)のノイズの原因と直し方

この記事でわかること

• RetroArchで「音がバリバリ・プチプチ鳴る」ときに疑うべき設定
• CPU負荷でも電源不足でもハードの故障でもない、よくある原因
• audio_max_timing_skewという設定の意味と直し方
• 原因を特定するために使える、RetroArch標準の統計表示機能

ラズパイにRetroArchを入れて、PC-98のレトロゲーム（np2kaiコア）を遊んでいたところ、音が「バリバリ」「ザラザラ」とノイズまみれになる症状に長いこと悩まされていました。

同じ画面・同じラズパイでSFC（スーパーファミコン）を遊ぶと音はクリアなので、機種依存の症状であることは間違いない。ただ、そこから先の原因究明にかなり時間がかかりました。最終的にRetroArchの1つの設定値を変えるだけで解決したので、同じ症状で検索している人のために手順と原因をまとめておきます。

症状

• ラズパイ4 + RetroArch + np2kaiコア（PC-98エミュレータ）でゲームを起動
• 音声が数十秒〜数分で「バリバリ」というノイズまみれになる
• 音量を下げても、音源設定を変えても症状は変わらない
• 同じ機体・同じ出力経路でSFCを遊ぶと問題なくクリア

先に結論：原因はRetroArchのaudio_max_timing_skewという設定

先に答えを書きます。原因は、RetroArchのretroarch.cfgにある

audio_max_timing_skew = "0.050000"

という設定値でした。これがデフォルトの5%のままだと、PC-98のように本来のリフレッシュレートがモニター側の60Hzと大きくズレている機種で、音声のノイズが発生しやすくなります。

対処法は、この値を広げるだけです。

audio_max_timing_skew = "0.150000"

0.05（5%）から0.15（15%）に変更したところ、症状はぴたりと収まりました。

なぜこれで直るのか

そもそも、PC-98のBGMは録音された音源データをそのまま再生しているわけではありません。ゲームのプログラムが「この音色・この周波数で鳴らせ」という命令をFM音源チップ（YM2608）に送り、チップ側がその場で波形を計算して音を出す、という仕組みです。np2kaiコアは、このチップの動作そのものをソフトウェアで再現していて、1フレームごとに音声波形をリアルタイムで演算し続けています。

つまり、映像を60Hzモニターに同期させるタイミングと、この音声演算のタイミングがズレなく噛み合っていないといけない、ということです。ここにaudio_max_timing_skewが関わってきます。

audio_max_timing_skewは、RetroArchの公式ドキュメントにも載っている正式な設定項目で、「コアが要求する動作速度を、画面のリフレッシュレートに同期させるために、どこまで速度を調整してよいか」の許容幅を決めるものです。

今回のPC-98(np2kai)は、コアが本来想定しているフレームレートが56.40fpsでした。一方、使っているモニターは60Hz固定です。RetroArchはこの2つを一致させるため、映像を60Hz（実測59.94〜59.96fps）に同期させつつ、音声側でわずかにピッチ・速度を補正して帳尻を合わせています。

問題は、56.40fpsと59.94fpsのズレが約6.3%あったこと。これはデフォルトの許容幅（5%）を超えていました。許容幅を超えると、RetroArchは滑らかな微調整では追いつけなくなり、音声ドライバが常に「書き込み待ち」の状態（ブロッキング状態）に陥ります。これがバリバリノイズの正体でした。

SFCで症状が出ない理由もこれで説明がつきます。SFC（NTSC）は本来59.94fps設計なので、60Hzモニターとほぼ完全に一致し、この補正がほとんど必要ないのです。PC-98のように、本来のリフレッシュレートが60Hzから離れている機種ほど、この設定の影響を受けやすいということです。

libretro公式のドキュメントにも「50Hzのコンテンツを60Hzで動かすような、コアのHzが大きくズレるケースでは、max skewをさらに高く設定する必要がある」という記載があり、今回の現象と一致します。

直し方（手順）

1. RetroArchを終了する
2. 設定ファイル（~/.config/retroarch/retroarch.cfg）を開く
3. audio_max_timing_skewの行を探し、値を0.05→0.15程度に変更する
4. RetroArchを再起動する

コアのフレームレートとモニターのリフレッシュレートのズレが大きいほど、この値を大きくする必要があります。ズレが小さいコンソール（SFCなど）では、そもそもこの設定を触る必要はありません。

RetroArchはメニュー画面から実行中にコアオプションを変更できますが、config_save_on_exitをfalseにしている環境では、終了時に設定が上書きされない代わりに、実行中の変更もメニュー経由では保存されないことがあります。確実に反映させたい場合は、いったんRetroArchを終了してから設定ファイルを直接書き換えるのが安全です。

原因を特定するために使った方法：RetroArchの統計表示

今回、原因の特定に一番役立ったのが、RetroArchに標準で備わっている統計表示機能でした。

retroarch.cfgの

statistics_show = "true"

を有効にして起動すると、画面の左上にCORE AV_INFO（コアが本来想定するFPSなど）や、VIDEO・AUDIOの詳細な統計がリアルタイムで表示されます。

このとき特に注目したのがAUDIO欄のBlockingという項目でした。実際にiPhoneでモニター画面を撮影して確認した数値がこちらです。

修正前はBlocking: 100.00%。音声ドライバが常に書き込み待ちの状態になっていたことが、この数値からはっきり分かります。

audio_max_timing_skewを広げた後はBlocking: 0.00%。バリバリノイズが消えたタイミングと、この数値がゼロになったタイミングがぴったり一致していました。

Underrun（音声データの供給切れ）は常に0%だったので、そちらでは異常が見えませんでしたが、Blockingの数値だけがはっきりと症状と連動していました。数値の変化がそのまま体感の変化（バリバリが消えた）と一致したので、これが決め手になりました。

音のノイズは録音して波形解析するといった方法も試しましたが、結局はRetroArch自身が持っている統計表示を見るのが一番手っ取り早い診断方法でした。同じ症状で悩んでいる方は、まずこの統計表示をオンにしてBlockingの値を確認してみることをおすすめします。

ちなみに、これは原因ではなかったもの

同じ症状で検索している方の参考までに、途中で疑って「違った」と分かったものも書いておきます。

• CPU使用率の高さ（測定したところ20〜40%程度で余裕があった）
• 電源不足・アンダーボルト（vcgencmd get_throttledで確認したが記録なし）
• 音源ボードの設定（SNDboardをいろいろ変えても無関係）
• FM音源エンジンの種類
• CPUエミュレーションの非同期化設定
• モニター側のアナログ出力経路（同じ経路を使うSFCは問題なかったため）
• バックグラウンドで動いていた別のサービス（Minecraftサーバーなど）

一見「ハードの不調」や「重いから」を疑いたくなる症状でしたが、実際にはソフト側の同期設定1行が原因でした。似たような症状に当たったら、ハードを疑う前に、まずはこの設定を確認してみてください。

まとめ

• RetroArchで音が「バリバリ」鳴るときは、audio_max_timing_skewを疑う
• コアの本来のフレームレートと、モニターのリフレッシュレートのズレが大きい機種（PC-98など）ほど発生しやすい
• statistics_showをオンにして、AUDIO > Blockingの数値を見ると原因を特定しやすい
• 直し方はretroarch.cfgの該当行を書き換えるだけ

古い機種のエミュレーションほど、動作クロックやリフレッシュレートが今のディスプレイの常識（60Hz）からズレていることがあります。ノイズが出たら、まずはこの「ズレ」を疑ってみてください。

余談：仕組みを知っていると、AIへの指示も速くなる

今回の調査は、実際にはAIと対話しながら進めました。振り返って思うのは、「FM音源はその場で演算して音を出している」「映像は60Hzに同期している」といった仕組みをこちらが理解していたからこそ、AIに対して的確な仮説を投げられたということです。

仕組みを知らないまま「音が悪い、直して」とだけ伝えると、CPU負荷や電源、音量設定といった当たり障りのない仮説を順番に潰していく、遠回りな検証になりがちです。逆に「フレームレートが違う機種だから、同期処理のどこかで無理をしているのでは」という当たりをつけられると、AIとの対話は一気に核心に近づきます。

AIが賢くなるほど、こちらの理解の深さがそのまま解決の速さに直結する、というのは今回とても実感したポイントでした。