[Major] Yoshi's Island built-in has major audio issues when rendering SuperFX 2 data on 2.21c/d/e, not on 2.21b

[Drakonas]

I have confirmed this with a friend's seperate Super NES Classic, and 2.21e has a major audio pitch fluctuation on the title screen when Yoshi's Island is rendering the SuperFX 2 island.

2.21b is reported by a couple friends to not have this problem.

I have uninstalled Hakchi, and tested this with an OG Flash and it runs fine, then installed Hakchi2 kernel from 2.21e and without syncing roms or installing modules the issue is there.

EDIT 1: Confirmed the problem on 2.21d as well. EDIT 2: Confirmed the problem on 2.21c as well.

EDIT 3: Video confirming slowdown: https://drive.google.com/file/d/0Bw4ThVOQsld0NDcyMFpXYnlsUkU/view?usp=sharing

[nex86]

Yea I can completely confirm this. c/d/e have the issue, b does not.

I'm going to try increasing canoe's process priority using "nice", if that does anything then I guess it might be something running in the background stealing CPU time.

other CPU demanding emulators (like n64 or psx) or FX games on Canoe might be affected as well.

EDIT 1 I had no luck with renice, it made it only worse, but I ran "echo 1400000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq" to overclock it to 1.4ghz and the sound was all fine.

EDIT 2 SOO after looking into this I found out that remote-exec is responsible for it. Killing this process made the game run fine without any sound issues. 265 1 root S 1644 0.6 3 0.0 {remote-exec} /bin/sh /bin/remote-exec

need we don't really need clovershell and remote-exec anyways when playing games right? can't these processes be killed after starting an emulator and restarted when exiting? The only reason I see to use them in games is to use telnet, but I think there should be a checkmark for debugging to keep them up when needed.

[shadowxau]

Can also confirm the issue.

Interestingly enough I can verify an almost identical sound issue when using the newly found "fix" for Seiken Densetsu 3 (Secret of Mana 2) Hi-Res text issue as per the following reddit thread:

https://www.reddit.com/r/miniSNESmods/comments/78chn3/seiken_densetsu_3_hires_working_in_canoe/

EDIT 1: I can confirm that the SD3 sound issue is substantially less noticeable when using hakchi 2.21b.

[DanTheMan827]

If the problem wasn't present on 2.21b, here are all the commits that affected system scripts

https://github.com/ClusterM/hakchi2/commit/124f65ddedbd41a2179c8b61fd6d634fa599aaf9 https://github.com/ClusterM/hakchi2/commit/d1a7a450dfd206de18fd4a988a52a5c5ff3aab44 https://github.com/ClusterM/hakchi2/commit/6bbdcdab42bae2cb94f2633d01e7e12116a997f3 https://github.com/ClusterM/hakchi2/commit/7d014b7da4b6d2af1e62ef7f665342cee0e1b467

I also noticed some audio issues when playing Kirby's Dream Land 3 during areas with a lot of transparency and on-screen enemies, but I just chalked it up to compatibility issues

[efgamer]

I couldn't imagine that Hakchi2 would affect the performance of the system in general because it's not neither an emulator nor a process that runs in background (correct if i'm wrong).

After you flashed the original kernel back did you use the "Uninstall" option? If you didn't then the mods might stay there just waiting to be started by the custom kernel that should be there but its not anymore because you flashed the original kernel back then by the time you flash custom kernel again all mods get active again taking CPUs and memory from the system causing issues with Canoe.

I don't know what I'm talking about so ClusterM must read this post and explain himself...

[DanTheMan827]

@efgamer There are two things I can think of that run in the background, the gamepad driver, and the clover shell daemon.

If the shell daemon is misbehaving, that could easily slow down the entire system.

It appears that remote-exec is responsible, that's part of clovershell I believe.

[efgamer]

@DanTheMan827 What version should I stick with until the fix then?

[Drakonas]

@efgamer it depends if you care about the slowdown on certain games. 2.21b doesn't have the problem (I have confirmed on 3 SNES Classics from people I know online) and 2.21c+ has the issue (also confirmed on 3 SNES Classics)

To answer your question, I tested each hakchi version by uninstalling hakchi entirely, flashing og kernel, factory resetting, and then flashing the custom firmware with the different version after erasing everything but dump, games_snes, and config. I did not sync games or install any modules. It was tested on fresh installs, using the built in Yoshi's Island.

If you need proof of the problem: https://drive.google.com/file/d/0Bw4ThVOQsld0NDcyMFpXYnlsUkU/view?usp=sharing Starts at about 1 minute in.

[efgamer]

@Drakonas I'm using 2.21d (portable). How do I back to 2.21b?

[DanTheMan827]

@ClusterM @madmonkey1907 I'm pretty sure I found the problem...

/bin/remote-exec has a while true loop with usleep 200000 at the end, /bin/usleep was removed in commit 124f65d

So basically, this code runs as quickly as possible, forever... where before it would only run every 0.2 seconds

if [ -f "$mpc_flag" ]; then
  echo Restart!
  rm "$mpc_flag"
  /etc/init.d/S81clover-mcp start
fi
if [ -f "$exec_flag" ]; then
  cmd="$(cat "$exec_flag")"
  rm "$exec_flag"
  $cmd
fi

[nex86]

so putting usleep back will fix the issue? Why was it removed in the first place?

[efgamer]

Can I back to 2.21b portable from 2.21d portable?

[DanTheMan827]

@nex86 Probably, I have no idea why it was removed though...

https://github.com/ClusterM/hakchi2/raw/690b60216f26582f39823eb8ca583338be62deee/mods/mod_hakchi/hakchi/rootfs/bin/usleep

You could download that and ftp it to /bin/, you'd then have to run chmod +x /bin/usleep from telnet

Alternatively, if you have an old portable version of hakchi laying around, the file is in mods\mod_hakchi\hakchi\rootfs\bin\

[DanTheMan827]

I pushed something that may fix it without re-adding usleep, but it removes some functionality that (as far as I know) is never used, that is, writing a command to /var/exec.flag to be executed within 200ms

Maybe there's another, better way... and maybe it was done that way for a reason...

remote-exec is at the very least, related to chmenu, chmenu touches the /var/exec.flag which causes remote-exec to restart the ui and load the new menu.

[nex86]

I fixed it now by bringing usleep back and created a temporary hmod for the community. writing something constantly to the nand isn't very healthy for the flash cells, maybe we can increase the delay or disable it completely when running games?

[The-MAZZTer]

The script is not writing to the nand constantly but checking to see if files exist and taking actions if they do. Presumably another process is setting those flags. I would bet the mpc_flag is set by the emulator when the user presses the reset controller combo, or by whatever process checks the reset switch when the user hits it. exec_flag is presumably set by the menu when the user selects an item.

My guess is Nintendo does not want to launch the emulator directly from the menu for memory usage reasons Instead the menu is allowed to quit and free up its memory while the remote-exec script launches the emulator. Remote in this case does not refer to networking but remote process as in a different process.

Disclaimer: I have not actually checked the NAND myself, just going off of what I am reading in this thread.

Anyways IMO the usleep find is probably the issue. Without it the command, the script would not pause during the usleep command, and the result is the script would consume as much CPU as it is allowed to which would be very bad for the performance of the emulator.

[nex86]

well, just to be safe I increased the delay to 500ms. not sure if something will be affected but at least it cost less CPU.

[The-MAZZTer]

Eh, no need to increase the delay. All it is doing every 0.2s is checking to see if two files exist. Without the delay it's delaying 0s which means it's running probably tens of thousands of times a second (if not more). with a 200ms delay it's running 5 times a second. So reducing to 2 times a second is not going to make much difference for CPU usage and will add up to a 300ms delay when launching games or returning to the menu. It was fine before, no reason to mess with it (messing with the built-in scripts was technically what caused this problem in the first place...)

[madmonkey1907]

root@CLOVER:~# ls -la $(which usleep) lrwxrwxrwx 1 root root 12 Jan 1 05:10 /bin/usleep -> /bin/busybox

[DanTheMan827]

@madmonkey1907 So is adding usleep back in from the previous commit just a placebo effect, or is there actually an issue with the remote-exec script?

I haven't tested anything myself since I'm not home right now, so I have no idea... I just noticed that the file was deleted.

[madmonkey1907]

I have no idea. run top to see if there is an issue with cpu consumption.

[nex86]

there wasn't much of a usage with remote-exec, maybe 1% but copying usleep back to /bin fixes the issue and basically puts remote-exec back to 0% usage. So it doesn't look like the busybox usleep is actually being used.

[madmonkey1907]

check if /bin/usleep is present and is a link to busybox without your fix applied. don't just rm /bin/usleep though, do a memboot after that.

[madmonkey1907]

I might know what's up. rm -f /bin/usleep ln -s /bin/busybox /bin/usleep replace busybox binary with this https://busybox.net/downloads/binaries/1.21.1/busybox-armv7l let me know if this fixes the issue.

[DanTheMan827]

How are you supposed to replace busybox and chmod +x when chmod is busybox?

[madmonkey1907]

For now, just do /var/lib/hakchi/squashfs/bin/busybox chmod +x /bin/busybox

[nex86]

or just replace the busybox binary in hakchi2\mods\mod_hakchi\bin and reflash custom kernel ?

I'm going to try this later.

[DanTheMan827]

Well, I had to copy the binary to a temporary folder, chmod +x it, rm /bin/busybox and then use the squashfs busybox to move it back to /bin/

It did seem to fix the problem though...

But @madmonkey1907, what was the actual issue?

[madmonkey1907]

nex86, yes, but don't reflash, just do a memboot. DanTheMan827, my love for upx. Since busybox binary is compressed, it was uncompressed each 200ms

[DanTheMan827]

@madmonkey1907 ah...

Well, you could still keep it compressed and use the couple kilobyte usleep binary separately

When you say memboot, do you mean "boot patched kernel from ram"?

I ask, because there have been times that I've borked the system requiring a complete re-install of hakchi... usually from a preinit.d script that I forgot the empty line at the end on that corrupted the entire preinit... if there's another way to boot back into a functional system, that'd be nice...

[madmonkey1907]

Yes, and yes. But keeping it uncompressed is unnecessary at this point. I switched to uncompressed months ago, which is why I didn't expirience this issue.

[madmonkey1907]

Yes, you can restore from memboot. It overwrites all mismatched files by those from initramfs.

[nex86]

oi I think leaving it uncompressed should speed some things up, and solve potential issues. and how much do you save anyway from compressing busybox? maybe 400K? lol I don't think there is a reason to leave it compressed.

do you have a uncompressed version of rsync as well?

[juanlin]

Replacing /bin/busybox with https://busybox.net/downloads/binaries/1.21.1/busybox-armv7l fixed the issue for me too.

[DanTheMan827]

another positive effect of being uncompressed, boot time should be shorter now as well...

If every system command is done through busybox and that binary is compressed, every command was essentially UPX packed... cp, mv, rm, cat, and so on...

[Drakonas]

The issue is somewhat fixed with that busybox but I am still getting a slight bit of fluctuation @DanTheMan827 not nearly as noticeable though, but if you run Yoshi and sit on the title screen with the island you can hear it if you pay attention.

[nex86]

with busybox being uncompressed it should take less cpu usage now. not sure what else there is in the background that needs cpu, clovershell maybe.

Also, is it normal that there are two clovershell processes running at the same time but each have a different PID?

[DanTheMan827]

@Drakonas After replacing busybox, I hear no difference with or without remote-exec running, maybe temporarily boot the original kernel from ram and see if it's still there?

[Drakonas]

@DanTheMan827 I booted OG kernel from RAM and it's near identical, but it has perfect audio. The busybox provided here still has tiny barely noticeable pitch changes if you listen closely. I did not link usleep to busybox though. Do I still need to do that? I only installed the replacement busybox executable.

UPDATE: It seemed to be residual data left in my savestate. Starting a fresh game fixed it.

[nex86]

alright, I replaced busybox in hakchi, I was gonna do a full reflash anyway

[DanTheMan827]

@Drakonas /u/mgede went and made a hmod of the changes in my branch, do you notice the pitch deviations with that?

https://drive.google.com/open?id=0B6sdXoz5SC55bENhQnRCVVI1NGM

The only thing I can think is that simply running remote-exec, even with uncompressed busybox, is just making the emulator glitch out randomly...

It could also be clovershell... you could try killing that and remote-exec, although you'll need to kill clovershell last obviously...

[ghost]

https://www.reddit.com/r/miniSNESmods/comments/78i9vv/temporary_fix_for_slowdown_loop_bug_thats_been/dovm9wq/

Cluster just commented this issue one hour ago in this thread stating that it: "Will be fixed soon."

Great news!

[nex86]

yea he already messaged me on twitter. I just wonder what method is he gonna pick to fix it :p

[DanTheMan827]

@Drakonas I booted the OG kernel from RAM and, to me, it sounded exactly like with the hakchi kernel...

It's very minor, but it's still there, even with the stock kernel...

[Drakonas]

@DanTheMan827 So it seems that the busybox excecutable that was provided causes game demo mode to break. Once it loads a savestate from a non-original rom, it plays it as normal for 30 seconds or so and then C8 errors. Going back to original busybox executable fixed that, but the Yoshi's Island problem remains.

[ajmi982]

And we need a proper clusterm fix. Case and point right here. :/

Sent from my iPhone. Please pardon any spelling or grammar mistakes.

On Oct 25, 2017, at 9:39 PM, 3rdN3rd notifications@github.com wrote:

So it seems that the busybox excecutable that was provided @DanTheMan827 causes game demo mode to break. Once it loads a savestate from a non-original rom, it plays it as normal for 30 seconds or so and then C8 errors. Going back to original busybox executable fixed it.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[megaDRONe86]

Fixed was just made in the 2.21f version.

[Drakonas]

Except all he did was replace the busybox executable with the same one that was posted here.... what a wonderful fix :/ Now game demo mode will be broken.. @ClusterM

EDIT: Sorry if I sounded harsh. I've just been frustrated lately haha. I can imagine you are chock full of stuff to do :(

[Drakonas]

I apologize @ClusterM It seems it may have been some other factor causing the game demo mode to break, but I swore I was getting it until I replaced the busybox with the old one on 2.21e. Consider this issue resolved. Closed.

[Frank-5]

So... Before I update my 2.21c to 2.21f, does the fix for this issue that Cluster made cause game demo mode for non original Roms to break or not? What was the "other factor" that caused game demo mode to break then? Also, what is the proper procedure for performing the update? There seems to be some confusing/ unclear info on what to do. Yes, I've read the Faq, and know what it says. But also the git comments indicate it isn't necessary to reflash the / a custom kernel either. Is it necessary to revert back to OG kernel first and basically start all over again?

[DanTheMan827]

Just select flash custom kernel and ignore the message about the hash not matching On Fri, Oct 27, 2017 at 7:33 PM Frank-5 notifications@github.com wrote:

So... Before I update my 2.21c to 2.21f, does the fix for this issue that Cluster made cause game demo mode for non original Roms to break or not? What was the "other factor" that caused game demo mode to break then? Also, what is the proper procedure for performing the update? There seems to be some confusing/ unclear info on what to do. Yes, I've read the Faq, and know what it says. But also the git comments indicate it isn't necessary to reflash the / a custom kernel either. Is it necessary to revert back to OG kernel first and basically start all over again?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ClusterM/hakchi2/issues/921#issuecomment-340126478, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwOZ74XkUj4rFIwJhNQXKm_1VKOsE2Oks5swnZNgaJpZM4QDfvV .