lr-armsnes and Retropie 4.4

[Used2BeRX]

@mitu said in lr-armsnes and Retropie 4.4:

@used2berx said in lr-armsnes and Retropie 4.4:

RetroArch version from the file:
[INFO] RetroArch 1.7.3 (Git b2ceb50)
(Selext+X) information, RA/Emu versions:
1.7.3 - Nestopia 1.49-WIP 5ecea44

These are the same versions included in 4.4, did you update the image through the RetroPie-Setup script ? You should post the whole runcommand.log file, not just the statistics line, there might be other information there that could give a hint.

Yes, actually. I did. After installing RP 4.3, I updated the install script. Then I ran "update all packages", but I declined when it asked about updating the OS and kernel itself. My thought was that I was just updating all of the emulators to the current versions?

At any rate, the screen I get for the RetroArch options is very different on 4.3 than it is for 4.4. In 4.3 we get the old screen with green bars. On my 4.4 image it has the soft blue RetroArch displayed that looks a lot like the PS3 options screen.

I have the 4.3 and 4.4 runcommand.log for All-Stars. Give me a minute to figure out how to post them here so you can see the differences.

BTW... the alsa_thread isn't even mentioned in the 4.4 log at all?

[Used2BeRX]

@mitu @dankcushions

Results on Super Mario All-Stars / lr-nestopia. Full runcommand.log files:

RetroPie 4.2: https://pastebin.com/Em3wPdUR
1.6.0 - Nestopia 1.48-WIP af3bd1a
NOTES: Absolutely zero audio stutter / slowdown. (With or without verbose logging taking place).

RetroPie 4.3: https://pastebin.com/eJf5Gb4h
1.7.3 - Nestopia 1.49-WIP 5ecea44 (Updated stuff right after installing 4.3)
NOTES: Minor audio stutter when game starts up, but then it is fine. (Only with verbose logging. No stutter otherwise).

RetroPie 4.4: https://pastebin.com/DR9BNzbP
1.7.1 - Nestopia 1.49-WIP 5ecea44 (Must have never updated this. Could this be the problem???)
NOTES: Audio stutter / slowdown plagues the game from start to finish and the games are virtually unplayable (With or without verbose logging taking place).

[mitu]

@used2berx said in lr-armsnes and Retropie 4.4:

At any rate, the screen I get for the RetroArch options is very different on 4.3 than it is for 4.4. In 4.3 we get the old screen with green bars. On my 4.4 image it has the soft blue RetroArch displayed that looks a lot like the PS3 options screen.
[...]

That should not happen with a stock image, the menu should show the RGUI and not the XMB menu (the blue one). Have you applied any configurations to the 4.4 image ?

Regarding the 4.4 image versions - it seems you did not update the image, you should update it - including the OS - then re-test. I'm not expecting it will be different, but you'll have the same base for testing - identical version on both systems - so we could easily pinpoint where the issue might occur.

Right now, it looks similar to this, which has been reported a few times with the 4.4 version, but I don't think you're using the 3.5' audio jack on your Pi Zero.

[Used2BeRX]

@mitu said in lr-armsnes and Retropie 4.4:

@used2berx said in lr-armsnes and Retropie 4.4:

At any rate, the screen I get for the RetroArch options is very different on 4.3 than it is for 4.4. In 4.3 we get the old screen with green bars. On my 4.4 image it has the soft blue RetroArch displayed that looks a lot like the PS3 options screen.
[...]

That should not happen with a stock image, the menu should show the RGUI and not the XMB menu (the blue one). Have you applied any configurations to the 4.4 image ?

I'm going to say no because I don't even understand what you're asking me here. How would I go about doing this? If I know what you're talking about then I should be able to tell you if I did or not. (At first I thought this was part of the SNES Mini skin, actually, so I switched to the NES Mini skin and it was still blue and there was no change in the speed/quality of the game).

Regarding the 4.4 image versions - it seems you did not update the image, you should update it - including the OS - then re-test. I'm not expecting it will be different, but you'll have the same base for testing - identical version on both systems - so we could easily pinpoint where the issue might occur.

I never ran the update for 4.4 I guess. I'll update it in a minute and let you know if there is any change. I'll re-run the test on All-Stars when I do. (Should I update just like I did before????? Update all, but then decline to do the OS/Kernel updates? I see you said to update the OS, but then you say "to have the same base to test". If I choose yes to OS/Kernel updates here than it will not be the same as my 4.3 image, will it?).

Right now, it looks similar to this, which has been reported a few times with the 4.4 version, but I don't think you're using the 3.5' audio jack on your Pi Zero.

No. That's not at all the issue I'm having. It's hard-core audio sputtering/stuttering that happens when you're running a game/emulator that isn't going at full speed (either because of hardware and/or software limitations). The game is also notably slower, and even when playing the 1st Super Mario Bros in this hacked rom the game runs extremely slow and has the audio stutter.

[mitu]

@used2berx said in lr-armsnes and Retropie 4.4:

I'm going to say no because I don't even understand what you're asking me here. How would I go about doing this? If I know what you're talking about then I should be able to tell you if I did or not. (At first I thought this was part of the SNES Mini skin, actually, so I switched to the NES Mini skin and it was still blue and there was no change in the speed/quality of the game).

I mean if you copied over any of the files in the configs folder. The stock image, as distributed by the RetroPie project, specifically disables the XMB menu driver and enables the RGUI (the green checkered menu). You should copy the /opt/retropie/configs/all/retroarch.cfg.rp-dist over /opt/retropie/configs/all/retroarch.cfg. Check that the file has the line

menu_driver = rgui

and NOT

menu_driver = xmb

As for the update, you could first update the packages only (no OS update) and re-test, but first you should disable the XMB menu driver for RetroArch.

I see you said to update the OS, but then you say "to have the same base to test". If I choose yes to OS/Kernel updates here than it will not be the same as my 4.3 image, will it?).

The 4.3 and 4.4 images are based on different Raspbian releases, so the OS will always be different. When I say "same base tot test" I mean you'll have the same RetroArch and Nestopia versions in both systems - so this helps to narrow down which update (OS/package/emulator/config ?) triggers the slowdown you're experiencing.

[Used2BeRX]

@mitu said in lr-armsnes and Retropie 4.4:

@used2berx said in lr-armsnes and Retropie 4.4:

I'm going to say no because I don't even understand what you're asking me here. How would I go about doing this? If I know what you're talking about then I should be able to tell you if I did or not. (At first I thought this was part of the SNES Mini skin, actually, so I switched to the NES Mini skin and it was still blue and there was no change in the speed/quality of the game).

I mean if you copied over any of the files in the configs folder. The stock image, as distributed by the RetroPie project, specifically disables the XMB menu driver and enables the RGUI (the green checkered menu). You should copy the /opt/retropie/configs/all/retroarch.cfg.rp-dist over /opt/retropie/configs/all/retroarch.cfg. Check that the file has the line

menu_driver = rgui

and NOT

menu_driver = xmb

I just checked my /opt/retropie/configs/all/retroarch.cfg and it has the line

menu_driver = "rgui"

It doesn't have xmb

But I just loaded up Super Mario All-Stars and I still get the blue screen and not the green one that I used to see in the RetroArch menu. Is there another possible way to make the blue screen happen? Maybe a /system/ based config got messed up or something?

As for intentionally doing this, I can say that I definitely didn't do anything. I've never used any configs other than what came on the pi (other than putting the experimental installer from zerojay... although I did put something called the "RetroPie Toolkit" on there that allows me to do some cool stuff like log into the Pi from my desktop to run commands from Windows. But I didn't do any options that I don't know what they do, and nothing that specifically says it would have changed this).

As for the update, you could first update the packages only (no OS update) and re-test, but first you should disable the XMB menu driver for RetroArch.

I just did. Now I show 1.7.3 - Netopia 1.49-WIP 5ecea44 in RetroArch.

I see you said to update the OS, but then you say "to have the same base to test". If I choose yes to OS/Kernel updates here than it will not be the same as my 4.3 image, will it?).

The 4.3 and 4.4 images are based on different Raspbian releases, so the OS will always be different. When I say "same base tot test" I mean you'll have the same RetroArch and Nestopia versions in both systems - so this helps to narrow down which update (OS/package/emulator/config ?) triggers the slowdown you're experiencing.

Okay. I didn't do the OS/Kernel, but I updated everything else. As I said, the blue screen RetroArch still shows up even after verifying that menu_driver line is as it should be, and there is no change to the bad performance of All-Stars. At this point I'm not going to re-test it for the runcommand.log file until I figure out how to get back to the Green RetroArch GUI.

[mitu]

Check if your NES system configuration file for RetroArch (in /opt/retropie/configs/nes) has the XMB display driver enabled. The file there should not be more than 4 lines.

[Used2BeRX]

@mitu said in lr-armsnes and Retropie 4.4:

Check if your NES system configuration file for RetroArch (in /opt/retropie/configs/nes) has the XMB display driver enabled. The file there should not be more than 4 lines.

lol... what the s***? I'd say it's a little more than 4 lines. It's 94kb. I did a search for menu_driver and it is, in fact, xmb.

Here's what my file looks like: https://pastebin.com/s6PjT2Bp

Any idea how this would have happened? I know I didn't write a 94kb CFG file in my sleep.

Incidentally, the SNES RetroArch screen is Green like it should be. (Although 7th Saga plays like crap in lr-snes9x2002 compared to how well it plays on my 4.2 version still, and I'll have to eventually be testing all 3 systems on that game as well).

I'm going to change that line in my NES config and see if things work better for the NES. In the mean time, feel free to give me your thoughts on what might have happened there. :)

EDIT: I changed that line to read rgui instead of xmb. That gives me the Green screen in RetroArch again, but sadly it doesn't improve the performance of the game.

RetroArch now shows 1.7.3 - Nestopia 1.49-WIP 5ecea44 on my RP 4.4 build.

[mitu]

Replace the contents of the retroarch.cfg (in the nes folder) with

# Settings made here will only override settings in the global retroarch.cfg if placed above the #include line

input_remapping_directory = "/opt/retropie/configs/nes/"
#include "/opt/retropie/configs/all/retroarch.cfg"

This should get you the stock settings.

[Used2BeRX]

@mitu said in lr-armsnes and Retropie 4.4:

Replace the contents of the retroarch.cfg (in the nes folder) with

# Settings made here will only override settings in the global retroarch.cfg if placed above the #include line

input_remapping_directory = "/opt/retropie/configs/nes/"
#include "/opt/retropie/configs/all/retroarch.cfg"

This should get you the stock settings.

Yeah. I actually did that by renaming retroarch.cfg to retroarchBAK.cfg then copying retroarch.cfg.rp-dist to retroarch.cfg. There actually did seem to be a bit of improvement, but not enough. It's still laggy and has audio stutter.

Now that we're updated to the same RetroArch and emulator, we've got the same RetroArch Green Screen, and we're using the default retroarch.cfg options, if there is nothing more you can think of to try tweaking (or un-tweaking) at this point, maybe I should just run another runcommand.log and show you the new results?

[Used2BeRX]

@mitu

I went ahead and re-tested. Here's the results: https://pastebin.com/Ptgmb9cj

It occurs to me again that the 4.4 is the only version I've tested out of the 3 that comes up with those alsa_thread errors. (This is not true. It happened with 4.3 as well after the update. But on 4.3 I still didn't have any problem with Super Mario All-Stars, so I doubt anything I try below is going to fix this. I'm still going to try it though.)...

I'm going to see if I can somehow fix that and force alsathread and see if this at least fix the NES portion of our issues here.

EDIT: Hmmmmmm.... I might be onto something here. I just tested 7th Saga with verbose logging to get the runncomand.log and the log for 7th Saga is showing the following errors as well:

[ERROR] Couldn't find any audio driver named "alsa_thread"
[INFO] Available audio drivers are:
[INFO] alsa
[INFO] alsathread
[INFO] tinyalsa
[INFO] sdl2
[INFO] null
[WARN] Going to default to first audio driver...

This would mean that in both instances (NES and SNES) and likely every other system on the Pi Zero using this 4.4 image, it is defaulting to the first option alsa instead of alsathread. I don't know how much impact this does or does not have on the speed of the emulation on the Pi Zero, but to the article here (https://github.com/RetroPie/RetroPie-Setup/wiki/Speed-Issues), you are supposed to put # Audio driver backend. audio_driver = alsathread for better speed.

I'll let you know if I can fix this or not and if it has any effect.

EDIT: Options for 6 audio_driver () when in the RetroPie Setup and inside the retroarch.cfg for "All" are as follows:

U unset / 0 alsa / 1 alsa_thread / 2 sdl2

Even if this doesn't solve my speed issues here, you guys may want to look into this? It seems that selecting this setting in the RetroPie setup makes the cfg file read alsa_thread when it's looking for alsathread. I'm going to manually change it and do another runcommand.log.

[Used2BeRX]

@mitu @dankcushions

Okay. I had to manually change the following entry in the /opt/retropie/configs/all/retroarch.cfg file:

audio_driver = "alsa_thread"

Changed it to...

audio_driver = "alsathread"

Re-ran SMAS on lr-nestopia with logging. Now all the alsathread errors are gone. (Please somebody else try this and tell me if there is a problem with the alsathread option after doing an update to the latest.

Unfortunately, this does not fix the lag and audio stutter in All-Stars either.

I'm going to try running 7th Saga with logging and see if it's any better. Not very hopeful though since All-Stars is still a problem.

EDIT: I had to also change the alsa_thread to alsathread in the SNES specific retroarch.cfg file since I also had it there. After changing it in both places I re-ran the game and now all of the alsathread errors are gone there as well.

Still does not improve the quality or speed of the gameplay in lr-snes9x2002 though. :(

[Used2BeRX]

Alright.... keeping it EXTREMELY SIMPLE from here on out. (at least that's the plan).

In RetroPie 4.3 (after updating all packages except for the OS/Kernel and overclocking the CPU), I have zero issues running Super Mario All-Stars NES in lr-nestopia. I also have zero issues running The 7th Saga in lr-snes9x2002. There are ZERO changes in the SNES runcommand menu options, and the default emulator is lr-snes9x2002.

Here are the ONLY things that I changed in the global configuration file before I began any testing in 4.3:

Video Smoothing (true)
Render Resolution (320x240)
audio_driver (alsa_thread) *

• "alsa_thread" doesn't even matter apparently since I get audio errors (in the runcommand.log) because choosing alsa_thread as an option in RetroPie Setup throws errors on every game launch since it is expecting alsathreadwithout the underscore instead. So it is defaulting to the first choice alsa anyhow. I'm not sure when this broke, but it happens on 4.4 and it happened on my 4.3 build after updating everything. So for testing the 4.4 I will NOT be changing the default audio_driver either. You could manually go into the retroarch.cfg and remove that underscore and it will stop the errors, but I didn't do that on my 4.3 build, so I won't be changing that option for the 4.4 build either.

These are the ONLY options I changed in my brand spakin' new 4.3 build. I did not change a single thing in either the NES or SNES retroarch.cfg files this time.

Currently, I'm in the process of making a 4th SD card. It is a fresh image of RP 4.4 for the Pi 1 and Pi 0. I will run both of these games with that new image after updating everything, including the OS/Kernel and ONLY making the changes above and I will post my results here.

The only other necessary change I am making that was also made to the 4.3 image that has no problem is overclocking the CPU. This is done by adding the following lines to /boot/cfg.txt:

arm_freq=1000
gpu_freq=500
core_freq=500
sdram_freq=500
sdram_schmoo=0x02000020
over_voltage=2
sdram_over_voltage=2

All testing is done using different SD cars on the exact same physical Pi Zero. They are all identical SanDisk Ultra 32GB cards.

[Used2BeRX]

@mitu @dankcushions @BuZz

Houston, we have a problem.

You can see what I did on my last post. I have fresh 4.3 and 4.4 installs of RetroPie for the Pi Zero that I'm running on the same physical Pi Zero.

"Super Mario All-Stars NES" in lr-nestopia runs slow and massive audio stutter in 4.4 (1.7.3 - Nestopia 1.49-WIP 5ecea44) but works fine in 4.3.

"The 7th Saga" in lr-snes9x2002 runs slow with massive audio stutter in 4.4 (1.7.3 - Snes9x2002 7.2.0) but works fine in 4.3.

This problem is very real and is now verified on my end. The only changes I made to either build are listed in the previous post. RetroPie 4.4 greatly reduces performance in both NES and SNES emulators.

However, I did test quite a few arcade/neo geo games and got them to work at what seems to be full speed on the 4.4. Doom/Doom II and the expansions work good as well. Quake runs like crap, even with a very small screen. I'm going to have to re-test that one now on the 4.3 build to see if it plays better there.

So.... thanks for all the help so far @mitu

What do I have to do at this point for you guys to take me seriously on this issue now? Just name it.

[Used2BeRX]

@mitu @dankcushions @BuZz

I took it upon myself to re-test both games in both the brand new 4.3 and brand new 4.4 builds. Here's the pertinent info, as well as pastebin links to the full logs...

4.3 SuperMarioAll-StarsNES lr-nestopia - 5 minutes (8:25:49-8:30:49)
1.7.3 - Nestopia 1.49-WIP 5ecea44
[INFO] Threaded video stats: Frames pushed: 18029, Frames dropped: 1.
Full Log: https://pastebin.com/cb5whqcw

4.4 SuperMarioAll-StarsNES lr-nestopia - 5 minutes (7:59:49-8:04:49)
1.7.3 - Nestopia 1.49-WIP 5ecea44
[INFO] Threaded video stats: Frames pushed: 14526, Frames dropped: 3.
Full Log: https://pastebin.com/mQvAB0AW

4.3 7thSaga lr-snes9x2002 - 5 minutes (8:18:46-8:23:46)
1.7.3 - Snes9x 2002 7.2.0
[INFO] Threaded video stats: Frames pushed: 18042, Frames dropped: 0.
Full Log: https://pastebin.com/6yJpR62T

4.4 7thSaga lr-snes9x2002 - 5 minutes (8:05:54-8:10:54)
1.7.3 - Snes9x2002 7.2.0
[INFO] Threaded video stats: Frames pushed: 14240, Frames dropped: 1.
Full Log: https://pastebin.com/um1KiuZK

Huge differences here. Pretty consistent loss of performance between the two examples too. If I'm reading that right, the 4.4 build is running both of those at about 4/5ths the speed of the 4.3 build?

Let me know if you need anything more from me. I checked the changelog for 4.4 and I can't imagine I'm going to be missing much using a Pi Zero. Most of my desired changes were in the 4.3 build that works great for me, but I will miss Kiosk Mode. I just did all of this for the community and to shed some light on a problem. It's in your hands now. :)

I'll be working on my 4.3 image. ;)

[mitu]

@used2berx said in lr-armsnes and Retropie 4.4:

Most of my desired changes were in the 4.3 build that works great for me, but I will miss Kiosk Mode

When you started with a 4.3 image and updated all packages, you've updated to the latest version or Retropie (4.4.2 now). You're basically running the latest versions of the RetroPie distributed software on Raspbian Jessie, whereas starting with a 4.4 image you're running the same software, but on Raspbian Stretch.

So the only difference is the OS. Upgrade the OS on the 4.4 image to the latest (as you already intend to do) and check that your overclock settings are applied, by using the vcgencmd get_config int command after the system is started.

[Used2BeRX]

@mitu said in lr-armsnes and Retropie 4.4:

@used2berx said in lr-armsnes and Retropie 4.4:

Most of my desired changes were in the 4.3 build that works great for me, but I will miss Kiosk Mode

When you started with a 4.3 image and updated all packages, you've updated to the latest version or Retropie (4.4.2 now). You're basically running the latest versions of the RetroPie distributed software on Raspbian Jessie, whereas starting with a 4.4 image you're running the same software, but on Raspbian Stretch.

Oh cool. So you mean that I will have Kiosk mode on my 4.3 build then?

So the only difference is the OS. Upgrade the OS on the 4.4 image to the latest (as you already intend to do) and check that your overclock settings are applied, by using the vcgencmd get_config int command after the system is started.

I already completely upgraded everything available to upgrade before running those tests.

Overclock settings are applied. Ran cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq after applying them and the output was 1000000

Those are the final results, with an overclocked Pi Zero with RP4.4 vs RP4.3. All testing was done on the same physical Pi, and the two images were applied to brand new SanDisk Ultra 32GB SD cards. The only configuration changes were what were stated above, and were the same on both rigs.

4.4 does not play NES or SNES at an acceptable level on a Pi Zero compared to how it performed on 4.3.

[mitu]

@used2berx said in lr-armsnes and Retropie 4.4:

Overclock settings are applied. Ran cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq after applying them and the output was 1000000

That may be so, but you should run the vgencmd command and compare the 2 systems. Your problem looks like it's related to the overclock, it looks like it's not applied on the Stretch image in the same way it's applied on the Raspbian image.

What happens if you remove the overclock on the 4.3 start image ? Do you get the same slowdown as in the 4.4 one ?

[Used2BeRX]

@mitu said in lr-armsnes and Retropie 4.4:

@used2berx said in lr-armsnes and Retropie 4.4:

Overclock settings are applied. Ran cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq after applying them and the output was 1000000

That may be so, but you should run the vgencmd command and compare the 2 systems. Your problem looks like it's related to the overclock, it looks like it's not applied on the Stretch image in the same way it's applied on the Raspbian image.

4.3 Image vcgencmd get_config int

arm_freq=1000
audio_pwm_mode=1
config_hdmi_boost=5
core_freq=500
disable_auto_turbo=1
disable_commandline_tags=2
enable_uart=1
force_eeprom_read=1
force_pwm_open=1
framebuffer_ignore_alpha=1
framebuffer_swap=1
gpu_freq=500
hdmi_force_cec_address=65535
ignore_lcd=1
init_uart_clock=0x2dc6c00
over_voltage=2
over_voltage_avs=0x249f0
over_voltage_avs_boost=0x2191c
overscan_bottom=48
overscan_left=48
overscan_right=48
overscan_scale=1
overscan_top=48
pause_burst_frames=1
program_serial_random=1
sdram_freq=500
sdram_schmoo=0x2000020
temp_limit=85

4.4 Image vcgencmd get_config int

aphy_params_current=547
arm_freq=1000
audio_pwm_mode=514
config_hdmi_boost=5
core_freq=500
disable_auto_turbo=1
disable_commandline_tags=2
display_hdmi_rotate=-1
display_lcd_rotate=-1
dphy_params_current=1091
enable_uart=1
force_eeprom_read=1
force_pwm_open=1
framebuffer_ignore_alpha=1
framebuffer_swap=1
gpu_freq=500
hdmi_force_cec_address=65535
ignore_lcd=1
init_uart_clock=0x2dc6c00
over_voltage=2
over_voltage_avs=0x249f0
overscan_bottom=48
overscan_left=48
overscan_right=48
overscan_scale=1
overscan_top=48
pause_burst_frames=1
program_serial_random=1
sdram_freq=500
sdram_schmoo=0x2000020

I'll let you guys try to translate that. Way over my head.

What happens if you remove the overclock on the 4.3 start image ? Do you get the same slowdown as in the 4.4 one ?

Strange.... I commented out all of those lines for overclock that I mentioned above. Still at 1ghz, but a lot of the other stuff is lower than I manually clocked it. I'm not sure why it won't go back down even though I commented all of them out.

7th Saga plays almost just as bad as it did on the 4.4 now. Super Mario All-Stars NES is slower, but is still much more playable than it was on 4.4.

Here's the new output when I comment out all the overclock lines with a # character:

After commenting out overclock lines in 4.3

arm_freq=1000
audio_pwm_mode=1
config_hdmi_boost=5
core_freq=400
disable_auto_turbo=1
disable_commandline_tags=2
enable_uart=1
force_eeprom_read=1
force_pwm_open=1
framebuffer_ignore_alpha=1
framebuffer_swap=1
gpu_freq=300
hdmi_force_cec_address=65535
ignore_lcd=1
init_uart_clock=0x2dc6c00
over_voltage_avs=0x249f0
over_voltage_avs_boost=0x27ac4
overscan_bottom=48
overscan_left=48
overscan_right=48
overscan_scale=1
overscan_top=48
pause_burst_frames=1
program_serial_random=1
sdram_freq=450
temp_limit=85

EDIT: I manually brought the Pi Zero 4.3 back down to 700mhz, which is what the /boot/config.txt file says is the default. I made the line read as follows: arm_freq=700. After a reboot, now it shows the same output as above, but the arm_freq is 700.

Re-ran both games and now they seem to play a bit worse than they do on the 4.4 Pi image. Probably not by much, but it seems more pronounced to me.

[Used2BeRX]

@mitu said in lr-armsnes and Retropie 4.4:

@used2berx said in lr-armsnes and Retropie 4.4:

Overclock settings are applied. Ran cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq after applying them and the output was 1000000

That may be so, but you should run the vgencmd command and compare the 2 systems. Your problem looks like it's related to the overclock, it looks like it's not applied on the Stretch image in the same way it's applied on the Raspbian image.

Well. It's not "my" problem. I already solved my problem by reverting to 4.3.

Just woke up from a long nap and figured there'd be a reply from somebody by now. Even if just to acknowledge this. :(

So.... Is anybody looking into this mitu? If I have this issue than any Pi Zero user that installed 4.4 is running into this as well, whether they know it or not. It's extremely hard trying to figure out how to configure anything to work right with the Zero. Not all that cool to be keeping them hanging with a 20-30% reduction in CPU speed because the overclock isn't working right.

I mean... we didn't know about that until 9 hours ago, but now we do.