先日からRetroArchでレトロパソコンを動かす事にハマっている！
特にX68000は、私自身がエミュレータを使ったことが無かったので、目の前で動いているのを見て新鮮でニヤけてしまう(^-^)
これあったらエミュレータ作らなくてもいーんじゃね…？とか思い始めてもいる(^^;
私的な用途であればHuman68kが起動すれば良いけれども、ものは試しに…とゲームを試してみてしまったのが運の尽き！サウンドが変になるのが気になってしまった！
そこからなんとか改善できないかな？の長旅に出るハメに(^^;
こんな設定してみました
まずはいきなり結論から！(^^)
Main Memu→Setting→Driversにある項目をそれぞれ変更した。
Video → xvideo
Audio → alsathread
MainMenu→Setting→Video→Synchronination
Vartical Sync(VSync) → ON
MainMenu→Setting→Audio→Synchronization
Synchronization → ON
このくらいだろうか…他にもこまめにいじってしまった項目があるかも知れないが、大きな影響はないだろう…と思いたい。
オプションを変更したら Main Menu→Quit RetroArch で一旦落とし、再度立ち上げよう。
その前に注意がある！！！！！
私の手元で実際に起きているのだが、DriverのVideoをxvideoに変更すると、それ以降の(F1で起動する)メニューが見えなくなってしまう。
メニューを開く必要がある場合には以下のファイルを変更しよう。
~/.config/retroarch/retroarch.cfg
video_driver = "xvideo" → "gl"へ変更する
これで起動すればメニューは見えるようになる。
もうひとつ。
この解決策はDevTerm A06でしか有効でない可能性がある(T-T)
以下、こんな感じで詰めていきました…的なお話なので、興味無い方はここで終了です(^^)
現象を絞り込む
サウンドが変になっている件、まずは何が起きているのかを正しく把握する必要がある。
しかしRetroArch自体のソースを見てるわけではない＆こんなおっきそうなプログラムの構造なんてすぐに理解できない、ということで、想像の域は脱していないことをお断りしておく！おくったらおく！(^^)
まずサウンドがどのように鳴っているのか…を書き始めると、すんごく大変！
ここではざっくり書くと、システムが音を鳴らすためのバッファを用意しているので、そこにシステムが必要というタイミングまでにデータを用意する…ということを繰り返す。
データを細切れにして、その都度必要なデータを作りながら渡していく。
サウンド自体は厳密なタイミングで鳴らされるので、それまでにデータが間に合わなければ、最悪は間違ったデータがそのまま鳴ってしまう…これが多くの場合ノイズとなって聞こえる。
つまり今回の不具合は、サウンドのデータ生成に間に合っていないんだろうな…と想像した。
CPU負荷を調べてみる
ただ……十分なほど高速なCPUで実行しているのになぜ…と疑問が湧く。
そこで手元にあるX68000 on RetroArchを試してみる事にした。
↑これが一番ちゃんと動いているRG351MPの動作状況。
本体でX68000を動かしながら、sshでログインしてtopコマンドで数値を見てる。
%Cpu0〜3を見ると、１つのコアだけに負荷が掛かっている状況で、全体的に見たら20%程度しか処理負荷が掛かっていない。CPU的には余裕のよっちゃんだ！
↑これがRG552で動かした時の状況。サウンドがノイジーになっている。
topコマンドが簡易的なものに置き換わってしまっているため、残念ながらCPUごとの負荷を見る事ができない。でもシステム全体では8%の負荷しか掛かって無く、RG351MPよりもさらに余裕の状態。
↑そして今回のメイン、DevTermでの動作状況。おもしろい事にCPUが平均に使用されている。もっともこれはゲームをメインとしたRGシリーズとは違い、汎用マシンとして動いているDevTermの宿命かもしれない。
動いてるタスク数がDevTermが239、RG552が193、RG351MPでは138だ。
うーん…この結果を見る限り、CPUパワーは有り余ってると言えるだろう。
サウンドの処理が追いつかなくなるほど逼迫した状況ではなさそうだ…。
ソースを大雑把に読んでみる
私は他の方が開発されたエミュレータのソースは、極力見ないようにしている。自分で作りたいというのが一番大きな理由なのだが、やはり何かを見てしまうと似てしまう可能性もある。
そんな事情により、過去にfMSXのソースの一部を見た以降は見ないようにしていた。
今回ばかりはそうもいかないので、最悪は開発中のMC68000エミュレータの開発を中止してもかまわんか…と思い、ソースを見ることに。
主要な部分のみを見てみた感じでは、表示１ラインごとにCPU駆動やペリフェラル、そしてサウンドの処理なども行っている。ラスタスクロールなどの水平同期の処理をきちんとしようとすると、こういう構造になる。
そして注目したのがサウンドデータ。このタイミングでデータの生成していたら、上に書いた「データの準備が間に合わない」という事はおこらないはずだ…。だってCPUパワーは有り余ってる。
でも実際にはサウンドのテンポがズレたりノイズが乗ったりする。
これらを総合して考えると、原因が別のところにありそうだ。
RetroArchの構造
全然理解していない私が構造を詳しく説明するなんぞおこがましくて出来ないが、頭の中に整理したことをつらつらと書いてみる。
まず私はRetroArchに対応したPX68kの、元となったソースをインストールしようと過去に頑張った事がある。その際、SDL(ライブラリ)をインストールする必要があったので、PX68kはSDLを利用して画面表示やサウンドを鳴らすことをしているんだな…という理解をしていた。
RetroArchのエミュレータはコアと呼ばれ、個別の共有ライブラリ(拡張子.so。shared object)となっていて、ある意味独立している。各コアはRetroArch側からの要求に基づいて動作するようになっている。
私の空っぽの脳みそで理解した構造はこんな感じ。
RetroArchはエミュレータドライバみたいになっていて、マシンフレームの実行を呼び出し、そこで作られた画像の出力、サウンドの出力などを個別のdriverで出力するようになっている…らしい。
この構造に基づいてメニューを見てみる。
メインメニュー、これがRetroArch全体のメニューとなっている。
メインメニューにあるSettingsというのが、RetroArchから呼び出される様々な項目の設定だ。
↑Driversの中身はこんな感じで、上の紙切れにあったVideoやAudioはここの設定を指している。InputやControllerなどはこだわったことがないが、切り替えたら効果あるのかも？
Audioはalsathreadに設定してる
名前から察するにThread化されるんじゃないかと思う。
CPUコアが複数あるマシンであれば効果があるのかも…と思い、おまじない的にコレにしている。
↑メインメニューに戻って、少し下の方にあるOptionsというのが、PX68k特有の設定だ。
PX68k特有の設定をするのはここのメニューとなる。
このOptionsとSettingsの切り分けが頭の中で理解できるまで、どこに何の設定があり、どんな影響がどこに出るのかがさっぱり理解できなかった(T-T)
UIが難しいよ！
さて、ここまでで出てきた要素を考えていってみる。
まずサウンドデータの生成については、CPUパワーが有り余っている事から問題無く出来ているように感じられる。
サウンド乱れる時、映像も遅れる…という現象が出ているけれど、PX68k側の処理が間に合っていないような感じがしない。
…という事は、疑うべきはPX68kというよりは、VideoやAudioのドライバなのではないだろうか…(-_-;; でもそんな事ってあるの？？？
各種ドライバを試してみる
サウンド不具合に関する原因がPX68k側に見当たらないので、疑惑の目をRetroArch側に移してみる。最も気になっているのはVideoのドライバだ。もしかしたらVRAMアクセスが異様に遅いんじゃないの？…と感じ始めた。
DevTerm A06のRetroArchの場合、[gl, glcore, gl1, vulkan, sdl2, xvideo, drm, x11, sixel, caca]の10種類も存在した。このうち、vulkan、drm、x11、sixel、cacaは指定すると起動しなくなった。こうなると手動でconfigファイルを変更しなければならない(T-T)
テストをしていくうちに、やはりVideoドライバを変更するとサウンドの鳴り方が変わることを確認。ちょっとうーんって感じではあるが、そういうものらしい。
そしてこの中で最も高速に表示ができたのはxvideoだった!
動くんだったらvulkanが一番速そうなイメージがあったのだが、そうではなかった！
ネットで探してみたらソースが見つかった。
少し中身を見てみたが、とても素直な作りになっているので、その分高速なのかな…。
この段階で一度Twitterへご報告(^^)
DEVTerm A06のRetroArch X68000、だいぶ改善されたかも！
— PocketGriffon (@GriffonPocket) 2022年1月25日
動画に音入るのかな…(･･;)
DevTermの場合は音というよりも表示の遅さに起因してたみたい。後ほど詳しく書くけど、VideoのDriverを変更して速くなった！#DevTerm #X68000 #RetroArch pic.twitter.com/wvDlCa2cM0
タイトルが表示されるところでちょっとだけ音のもたつきが起きる。
うーん…せっかくだからこれもキレイに直らないかなぁ……。
そう思って今度はPX68k側のオプションを触り始めた。
↑このメニューを下にたどっていくと……
Audio Desync Hackという項目があった。
名前から言ってちょっとドキドキする(^^;
下に流れている英語…を読むのは大変だったので、ソースにあったコメントを要約すると「サウンドがズレないように出来る限り頑張るよ」的な事が書いてあった。Hackというからには少し不具合が出る可能性もあるな…と思うけど、試してみることに。
するとどうだろう、音ズレもキレイになくなって再生出来るようになった！(^-^)
この状態でしばらく見ていたが、CPUの処理負荷も特に変わらず動いてるようだ。ただ、ソフトによってはSegment Faultでオチてしまうケースもあったので、完璧とは言い難いかも知れない…(-_-;;
ちなみに同じような対策がRG552でも出来るだろうか？と思い試してみたが、そもそもVideoドライバにxvideoが存在しない上に、ユーザーによるドライバの変更は許されていないようだった…。
ゲーム機では素直にPX68k側のオプションでCPUクロックを上げつつNo Wait指定した方が安全そうだ(^^)
よーし、だいぶRetroArchの構造を理解できたぞ(^^)
これはこれで副産物的にオッケーということで、今回は終わりにしよう！
ではまた次回！(^-^)ノ
