search

BinBashBanana / webretro

RetroArch in your browser
https://binbashbanana.github.io/webretro/
MIT License
240 stars 342 forks source link

Major performance increase Audio Fixes #101

Open thelamer opened 7 months ago

thelamer commented 7 months ago

I got some cycles to go through my cores and a user pointed me back to your cores in https://github.com/linuxserver/emulatorjs/issues/130. Ethan at EmulatorJS discovered that rwebaudio was blocking the thread and causing slowdowns a bit ago: https://github.com/libretro/RetroArch/pull/15479 That was one part of the puzzle. Then in later versions of Retroarch ( I am using the current release) they implemented resampling quality along with the playback rate on top of using openal audio. The final missing piece was bumping it down and using 44100 for Chrome and Safari merged here: https://github.com/libretro/RetroArch/pull/16079

I went ahead and used your instructions to get 99% of the way to a core for the current release with these default setting patched in (great work btw on docs) and this is your current n64 core:

https://github.com/BinBashBanana/webretro/assets/1852688/fdeda31e-c638-4248-bfe3-53009622ae6e

And the new one built with the same logic for mupen but updated retroarch and default audio settings:

https://github.com/BinBashBanana/webretro/assets/1852688/84ad8bbc-340e-4791-b1dd-24d440ac5f85

BinBashBanana commented 7 months ago

Awesome!! I really gotta get back on this project. First off I want to get upstream compatibility -- hopefully that means getting a bunch of stuff merged -- then I want to see about dynamic linking. Thank you for this!

thelamer commented 7 months ago

You and me both, I really don't want to have all this stuff forked off all over the place. Would be nice to ingest directly from libretro for the most part. We should try to get a pipeline setup in github workflow to spit this stuff out with git submodules and patches initially. I started on that when I went on a build spree this weekend, but it devolved into copies of folders all over the place as I had to keep moving around what emsdk I was using and modifying the retroarch repo to play nice with the specific core.

ethanaobrien commented 7 months ago

Might be worth modifying my build script

I can also give y'all the bash script I use for my nightly core builds if y'all want. I also do package my own version of emscripten (debian) so its easier for me to manage.

Just some suggestions!

thelamer commented 7 months ago

Might be worth modifying my build script

I can also give y'all the bash script I use for my nightly core builds if y'all want. I also do package my own version of emscripten (debian) so its easier for me to manage.

Just some suggestions!

When it comes to the cores we are all on the same page I feel like, it only really gets divergent when it hits the retroarch project where I want pure cores, emulatorjs hooks in and externalizes all functions, and webretro does lighter externalization. Some cores are easy, but many are way over my head as to how you would achieve homology with the other ports like mupen64 and beetle-psx. Optimally libretro would be spitting out the bc files and forking would happen from there for frontends. The only changes I make on my side really is on beetle-psx crippling PGXP as it needs like 500 megs of ram and makes it impossible to load full games properly on most device browsers. https://github.com/thelamer/beetle-psx-libretro/commit/22f48c2786c96fd0b3692816e993eadc921b9cd8

Other than that the webretro patches and emulatorjs forks do way more to ensure compatibility with emscripten.