Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Major performance increase Audio Fixes #101

Open
thelamer opened this issue Jan 7, 2024 · 4 comments
Open

Major performance increase Audio Fixes #101

thelamer opened this issue Jan 7, 2024 · 4 comments
Labels
discussion discussion enhancement New feature or request

Comments

@thelamer
Copy link

thelamer commented Jan 7, 2024

I got some cycles to go through my cores and a user pointed me back to your cores in linuxserver/emulatorjs#130.
Ethan at EmulatorJS discovered that rwebaudio was blocking the thread and causing slowdowns a bit ago:
libretro/RetroArch#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:
libretro/RetroArch#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:

dk-old.mp4

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

dk.mp4
@BinBashBanana
Copy link
Owner

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!

@BinBashBanana BinBashBanana added enhancement New feature or request discussion discussion labels Jan 7, 2024
@thelamer
Copy link
Author

thelamer commented Jan 7, 2024

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
Copy link

ethanaobrien commented Jan 7, 2024

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
Copy link
Author

thelamer commented Jan 7, 2024

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.
thelamer/beetle-psx-libretro@22f48c2

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion discussion enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants