Retroarch Lag Issue

[DJ Manny]

I have tried 2 versions of retroarch that are known working with the steam link 1.6.1 and 1.6.7. Both have a issue with lag after playing any emulator/rom after a few minutes. I have been unable to find any solution for this even though all emulators run very well for a few minutes before slowly having the video/sound slow and lose frames. If anyone knows any solutions or more information I would greatly appreciate it. I have 2 steam links and both have this same issue which leads me to believe it should be a common issue.

[EdszxNeo]

It is, just look at the Retroarch 1.6.7 thread, nothing we non-devs can do about it for now, i'm just hoping that the upcoming official retroarch 1.7.0 build resolves this issue.

For now, you can just use "change monitor index" or any other option that reloads the video feed, it resets the framecount back to 0.

[DavidHelkowski]

I compiled Retroarch the latest commit ( as of 11/24/2017 ) of libretro from github several weeks ago for the Steam Link. I didn't play games for very long, but you can give a try at using the version I compiled to see if it has the same issue. You can grab the compiled binary from here: https://livxtrm.com/steamlink/retroarch.7z The version will report 1.6.9, and should be the latest version of retroarch available up till that date.

It is just the raw binary; you'll need to ssh replace the main binary from one of the other retroarch steam link installs that are here on the forum. ( after extracting it from the 7zip archive of course... )

Let me know if it solves the issue for you.

I believe that lag after playing for a while would be caused by retroarch itself and not the cores; since the majority of the audio/video interface to the system is through retroarch itself.

If the lag occurred constantly that would certainly be an issue with the core you are using.

As EdszxNeo stated, I doubt anyone on these forums knows enough about Retroarch to pin down exactly what is causing the lag... You would need to post something somewhere a Retroarch developer would look.

[EdszxNeo]

livxtrm původně napsal:

Let me know if it solves the issue for you.

Just came back from an hour of testing, the GUI reports the version is 1.6.9

Tested with mGBA (the one included in the v1.6.7 package) and Castlevania: Aria of Sorrow (U), framerate starts to degrade after 12000~15000 drawn frames, just like before, but in general, the emulation is now marginally faster (like 4fps gain vs v1.6.7)

In the case of PSX ReARMed and Crash Team Racing (U), the speed is just like with v1.6.7 (41 fps average) and starts degrading as usual after 12000~15000 drawn frames.

Even if the new build didn't solve the main problem, it stills performs a little bit better, thank you very much for sharing it.

[DavidHelkowski]

My mistake. I built it from the latest commit of libretro several weeks ago. I just assumed that since 1.7 was being discussed that I would get it when doing that. The latest available version is still 1.6.9; they have not bumped the version yet anywhere. I have corrected the above post to reflect this to avoid confusion.

The binary provided was built on a Fedora server... I failed to record all the details of how I did it. I am going to do a new build all over again from scratch with a fresh copy of everything and the latest commits from libretro. This time I will pay more attention to the steps so I can explain what if anything is different from just plain using the SDK to build the latest libretro.

Am going to give another attempt at building the cores. The cores do not build correctly by default with the setup from the SDK; will need to dig into making that happen again.

[DJ Manny]

Thanks for the update will keep my eye out for any solutions. Hopefully it gets released for steam link as mentioned in the retroarch roadmap.

[DavidHelkowski]

Just finished rebuilding mgba from source. I have no idea if it works or not. The so file for libretro seemed to build. The build process then crashed attempting to build the opengles2 support. I think that is only for the frontend though, and is not used when libretro is used.

The libretro so I built doesn't seem to depend on anything except what should be on the steam link. I haven't tested the so yet; but feel free to give it a try. Maybe it will improve performance or work better?

Build from commit 17801df8167e24d98b96495a43b0f9550ade8f30 of
https://github.com/mgba-emu/mgba.git

eg: readelf -d mgba_libretro.so shows:
0x00000001 (NEEDED) Shared library: [libm.so.6]
0x00000001 (NEEDED) Shared library: [libz.so.1]
0x00000001 (NEEDED) Shared library: [libpthread.so.0]
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x00000001 (NEEDED) Shared library: [ld-linux-armhf.so.3]
All of these libs appear in /lib on the steamlink...

https://livxtrm.com/steamlink/mgba_libretro.7z

This is essentially just build using the following cmake command and the provided SDK:
cmake -DBUILD_SDL=ON -DBUILD_GL=ON -DBUILD_GLES2=ON -DBUILD_QT=OFF -DBUILD_LIBRETRO=ON -Wno-dev -DUSE_ELF=OFF -DUSE_SQLITE3=OFF -DUSE_EPOXY=OFF -DUSE_MAGICK=OFF -DUSE_LIBZIP=OFF -DOPENGLES2_INCLUDE_DIR=/home/steam/steamlink-sdk/rootfs/usr/include -DOPENGLES2_LIBRARY=/home/steam/steamlink-sdk/rootfs/usr/lib -DUSE_DEBUGGERS=OFF .

I also added this line near the top of the CMakeLists.txt file for mgba:
INCLUDE(/home/steam/steamlink-sdk/toolchain/steamlink-toolchain.cmake)
I am not sure doing so made any difference.

[EdszxNeo]

livxtrm původně napsal:

Just finished rebuilding mgba from source.

Thank you very much for your efforts livxtrm, i'll try this extensively tomorrow and let you know how it goes.

[DavidHelkowski]

I pulled the latest changes for retroarch and rebuilt the main binary. I used slightly different config options than those set in the build script in the sdk example directory. The config I used was:
./configure --host=$SOC_BUILD --disable-alsa --disable-pulse --enable-neon --enable-opengl --enable-opengles

This does not disable threads, and it does not disable shaderpipeline.
I am not sure why threads are disabled in the example; I would think having threads would increase the performance...
latest build here; will date them from here on out also: https://livxtrm.com/steamlink/retroarch_12-17-17.7z

The latest changes do seem to include a bunch of refactoring for opengl; so hopefully it helps some with the problems that are being seen.

For giggles; since I wanted it to give it a try, I also rebuilt bsnes mercury under the performance profile. Bsnes notably also emulates gba... You could give it a shot.
Build of that here: https://livxtrm.com/steamlink/bsnes_12-17-17.7z
Just tested this bsnes core: Crashes. Does not work. Don't bother trying it.
Have been attempting to figure out what is happening. I ran a non-stripped version of retroarch on gdb; it appears to crash trying to free a null pointer. I have some loose speculation that the system doesn't have enough memory to run it. If I run 'top' while attempting to run it memory decreases down to 2mb free then it crashes and returns to the launcher.

It appears swap is not even enabled in the kernel that is built for the steamlink. So there is no way to attempt testing adding swap memory from a USB device to see if more memory would let it function.
From kernel conf of steamlink: "# CONFIG_SWAP is not set"
Really it is kind of frustrating that we can't run a kernel with more options.

Steam link dev people: Please enable swap for those of us who want it in the next build.

[EdszxNeo]

This is my report after 2 hours of testing the new build (retroarch_12-17-17.7z)

The first thing i noticed is that the GUI now has a cute wave animation in the background, i think it's related to shaderpipeline not being disabled, it looks good and doesn't affect the performance at all, (the wave animation can be changed to other ones like snow or dots, those kill the framerate completely)

There are some extra options in general, but right now the only one i can remember (and the most important) is "threaded video", more on that on the next paragraph.

My current settings are a bit changed in comparison to the default configuration, most notable changes are:
Vsync: off
Fullscreen Windowed: off
Threaded video: on
Audio sample rate: 44100hz
Audio sync: off
My link is currently outputting at 720p 59.94hz

First test, GBA (with the new mGBA core from yesterday)
Game: Castlevania: Aria of Sorrow (U)

The performance improved, a lot, but the framerate is not constant, it plays at 60fps for like 10 seconds, and then slow down to like 30fps for 10 seconds, and then it comes back to fluid 60fps for 10 more seconds, and it goes like that, i think the problem is related to maybe the CPU or RAM being at max capacity, because the change in framerate isn't even happening when moving or changing scenes, if i just stay without moving, the framerate stills acts like that, even with that problem is very much an improvement in relation to the old 1.6.7 retroarch binary and mGBA core, its the first time it reaches such high framerates in this game.

Second test, PSX (with the PSX reARMed core from the 1.6.7 package)
Game: Crash Team Racing (U)

The framerate improved between 8 and 10 fps, it's much smoother and nicer to play now, it's still not perfect, but 50~ frames is not bad at all, if i didn't have to cope with the audio crackling related to sub-60fps rendering i would have no problem with that, in this game the performance was consistent, unlike those 30>60>30 spikes in mGBA.

Something that surprised me, is that now the savestate's saving and loading is extremely fast, for all cores, GBA games save the state in like a split second now, and PSX games just take like 2 seconds (used to be like 10).

In relation to the 12000~15000 bug, i didn't noticed it with the PSX game, the GBA game did started to get slower at like 30k~35k frames now, but i think it's not related to the same thing, it's probably because the GBA core is maxing out the CPU or RAM too frequently.

Even if all the problems weren't solved, this update was a great step forward, huge thanks to livxtrm for his help.

[DavidHelkowski]

Thank you EdszxNeo for trying out the various builds and providing detailed information. For myself I don't know the details of what would cause the problems exactly, but the more information the better for whoever comes along and actually knows.

All I can really do is attempt to build things with reasonable settings and hope the latest versions are improved. I am glad that actually does help some. I would like to see the steam link become a reasonable alternative to Raspberry Pi, as so many people have steam links.

I have rebuilt the latest git version of PCSX Rearmed.
Can be found here: https://livxtrm.com/steamlink/pcsx_rearmed_10-17-17.7z
Built from https://github.com/notaz/pcsx_rearmed with the commit dated 10-17-2017
CFLAGS set to -march=armv7-a -mfpu=vfpv3-d16 -O3
So has additionally been stripped ( removed debug symbols ) after compile to reduce size.
Good luck.

[EdszxNeo]

livxtrm původně napsal:

I have rebuilt the latest git version of PCSX Rearmed.

Thank you for the new build! i'll try this one tomorrow and post my results, it would be great if you could compile newer versions of snes9x2002 (or any other SNES emulator) and picodrive, the current build of snes9x has some major problems with many popular games (inputs not working, graphic corruption, invisible sprites) and it makes them unplayable, thank you in advance again.

[ҳ̸Ҳ̸ҳ SauS™]

Always fun when people don't come back after they said they'll go test and post results.

Really helps other people /s

[Mechanite]

Since we're half a year later, I guess I might as well as, was the issue ever figured out?

[DJ Manny]

Nope issue is still not fixed to my knowlegde. Its due to not being able to install a custom os different from the one included.

[GigaCat]

So I diddled around in settings, and this is what I’ve observed:

- RGUI works just fine and runs at a stable 60FPS, which led me to suspect something in XMB. The difference appears to even affect emulator performance. Nestopia has less dropped frames and less audio glitches, nearly none. FCEU runs even better than that.

- Regarding XMB, I did a ton of things. I even doubted that the darn ribbon was truly disabled, so I enabled shaderpipeline and recompiled RetroArch just to be certain it could be disabled by my own hand. Nope.

- Switched fonts to something that doesn’t require much in the way of antialiasing, and freakin’ voila. The pixel font used in RGUI brought XMB’s operating framerate from 20-30 to ~60FPS.

Ultimately, the 2 things that appear to heavily affect the framerate are the font and icons. With simple, smaller icons, it runs better than default. With no icons at all, it’s perfectly smooth, but you can’t see where you’re navigating. I’ll cook up a tiny icon set and test some more later.