Closed rcork closed 8 years ago
This is something best reported upstream probably. We do not develop/maintain all the emulators we ship with. @gizmo98 knows more about this than me.
I can confirm the same issue but yes should be sorted upstream as it's unrelated to RetroPie (unless there is some audio setting that was missed with the merges)
@rcork please try another video plugin and report if audio lag persists.
anecdotally, i get the same audio lag issues with mupen64plus latest builds. eg on mario 64 i get a slight audio lag with the rice plugin (but the textures and lighting are off and it performs worse), and a lot of audio lag with the gles plugin (yet it performs and looks perfect).
were older versions using some sort of alternative audio plugin?
Please post your ricevideolinux.ini if mario64 is corrupted.
RiceVideoLinux.ini has two Mario64 entries. If your rom has another hash settings will not be applied. Mario64 needs ScreenUpdateSetting=6.
{ff2b5a632623028b-45}
Name=SUPER MARIO 64
FastTextureCRC=1
AlternativeTxtSizeMethod=1
ScreenUpdateSetting=6
{36f03ca0d2c5c1bc-50}
Name=SUPER MARIO 64
FastTextureCRC=1
AlternativeTxtSizeMethod=1
ScreenUpdateSetting=6
@gizmo98 i always wondered about those hashes. They don't appear to be md5 hashes. How do we compare our roms to what's in RiceVideoLinux.ini?
I don't know how rice calculates the hash code. If you start a game rice adds the hash code of your rom at the end of the file. So if you post the hash code i can add it.
I can concur with what objectchris posted.
When running Mario 64 on the latest Mupen64plus binary in the latest RetroPie image using the gles plugin I get about a full second of audio lag. There is less audio lag with the rice plugin, but as he said the game's textures and lighting are inaccurate when using rice. The gles plugin is the only one of the three that runs the game properly, and this audio delay is the only problem with it.
It wasn't a problem in previous builds of Mupen64plus on RetroPie, from what I gather from YouTube videos and forum posts. I do believe that the audio plugin was recently changed, as I spotted a different name for it in the mupen64plus.cfg file in a YouTube video from a few months ago.
What's the problem with GLideN64? If you use a low screen resolution this plugin should run fine.
@gizmo98 Oh, really? When I first ran it through Glide64 it was running at like 5fps and stretched across my whole 1080p screen. I'll look in the config file when I get home later tonight and try changing the resolution. Thanks.
If you start mario64 press x or m and set output screen resolution there. GLideN64 is the most accurate video plugin atm but it needs low resolutions (VGA) to run at a playable speed.
@rcork please update RetroPie-Setup and do a source based installation again.
@gizmo98 Are you talking about launching into the RetroPie options menu when using the Libretro version of Mupen64plus? If I set the default emulator to the standalone Mupen64plus_GlideN64 there and then change the resolution from that same menu, Mupen64 standalone will honor the resolution that I set?
I noticed that while both rice and gles plugins launch into Mario 64 at a 4:3 aspect ratio (not sure which resolution), GlideN64 by default stretches to fill the screen.
@gizmo98 Do you want me to use the Retropie SD image and then launch RetroPie setup and choose source, or use Rasbian, download RetroPie-Setup and do a clean source install?
@rcork close emulationstation with F4 key press and type:
cd RetroPie-Setup
git pull
sudo ./retropie_setup.sh
Select option 5 "Install individual emulators". Select mupen64plus and a source based installation.
@ScOULaris yeah when you launch a game. And it does not support aspect ratio settings atm.
@gizmo98 So basically this is from the same menu where I select the default emulator, right? I'm changing the video mode to 640x480? Or is there a way to change the rendering resolution for the standalone Mupen64plus_GlideN64 from there as well?
Yes.
FYI my RiceVideoLinux.ini has the same settings for mario 64 as posted above. there's no new hashes at the end so I assume it's the right hash.
I should say the visual corruption is quite subtle - the alpha around the clouds in the beginning is ugly, the game looks slightly washed-out (lighting issue?), the fonts have a weird filtering effect that makes them look a bit ugly, and the frame rate is worse than gles, but still perfectly playable. I probably wouldn't know it's bad if I didn't have the gles to compare with!
also this sound issue affects mario kart 64 also. i'll try glide but if the performance is worse then it's probably going to be bad news for mario kart 64 - that game only just hangs on in multiplayer as it is!
I have built new binaries for mupen64plus now since @gizmo98 's changes.
I'll test them later when I have time. Hopefully the new binary fixes the load state crash
@objectchris there are differences between all video plugins and there is a rice plugin with even more visual issues. Please update mupen64plus. Audio lag should be better now. At least i hear no big delay between mario punching sound and visual appearance.
@gizmo98 Update the mupen64plus binary or from source? Was a change recently applied that would fix the audio lag issue with the gles plugin?
@ScOULaris I reverted some changes. I removed the buffer underrun message a month ago. This modification seems to cause increased audio lag. Jools has already updated binaries.
@gizmo98 Just installed the latest binaries, but now i notice an error when it loads and then it quits out - saying it can't find 'libEGL.so' ?
I accidently must have had raspbian libEGL installed again on one of my development chroots. I'll sort it.
I have uploaded a new binary.
Hm. I just updated to the newest binary, and I'm getting the same audio lag as before. I only tried Glide64 so far, but I'll test the gles plugin for audio lag when I get a chance later tonight.
Ok i updated Retropie, then compiled mupen from source, and load problem is fixed and OMX audio lag is gone. Looks like the code changes @gizmo98 made resolved the issue. I tried both rice and gles.
So I'll need to update from source to get those code changes? I was under the impression that the binaries had been updated with them, so I updated my binary. The audio lag still persists afterward. When I have time to spare tomorrow I'll try updating from source. Is it necessary to update Retropie Setup beforehand? I just set mine all up and I'm a bit reluctant to update Retropie before I get more comfortable with it.
I will rebuild binaries again, I may not have pulled in script changes when I built it as I didn't realise @gizmo98 had committed directly to retropie-setup with different github address for the audio driver
Perhaps you should stick with the pc for n64 emulation if you arent comfortable with updates as the pi will always be hit and miss.
For updating retropie: https://github.com/RetroPie/RetroPie-Setup/wiki/Updating-RetroPie
I can also confirm that lowering the video resolution to 640x480 on gliden64 vastly improves performance but still is sporadic.
they are updated again.
@joolswills sorry for the confussion. I will push all necessary changes upstream if i have some time.
NP. I hadn't been following the thread completely. Thanks for the contributions :)
Updated my Retropie Setup Script and to the latest mupen64plus binaries, and the audio lag is gone. Thanks to both of you for addressing this issue. :)
I just tested the binaries and while audio lag is gone, the load state still causes an unaligned exception on Raspberry Pi 2. If i compile from source, then it works perfectly. For now i'll just stick with compiling mupen myself.
Updated setup script and just tried it both from a source recompile and binaries, and issue still seems to be there with gles2n64. eg, in mario kart 64 in the menus (seems to be the same in any game but obvious there when you should get a sound as soon as you press a button). Perhaps I've done something wrong?
Do you use hdmi audio?
@gizmo98 Yes
Then i have no clue at the moment.
as of https://github.com/RetroPie/RetroPie-Setup/commit/5db5c02e11c257fd4014d40b2309f5ccd6090c9f load state no longer crashes
Running the latest Retropie 3.2.1 SD image and using mupen64plus+rice for Super Mario 64. When i try to load state, mupen64plus crashes with an alignment exception. I found that if i use Retropie_Setup script to manually compile mupen64plus, then load state works. However, the latest version of mupen compile from source suffers from audio lag when using OMX audio (which is the default). Any suggestions?