Critical freezing and audio loop in v4.8.2.1 – Structural Vulkan issues on Intel/AMD

Dear IPACS team,

I’m writing this because I’m at my wits' end with the latest update v4.8.2.1. Since the transition to Vulkan, the sim has become completely unusable on my setup, and after days of testing, I’m convinced there is a fundamental issue with how the new engine interacts with Intel Macs and AMD GPUs.

The Issue:
Regardless of the aircraft (testing mainly with the Q400), flight plan, weather, or time of day, the simulator consistently freezes. It starts with the audio stuttering/looping into a high-pitched "crackle," followed by a total screen freeze. The app doesn't technically "crash" to desktop; it just hangs indefinitely, forcing me to kill the process via Activity Monitor.

Everything I’ve tried so far (and nothing worked):

1. Audio Engine Tweaks: I noticed the log showed the sim forcing a 192kHz sample rate. I manually edited the main.mcf to force 44100Hz and increased the audio_buffer_size first to 1024, then 2048, and finally 4096. Even with a massive buffer, the audio still breaks and the sim freezes.
2. Vulkan Threading: I tried to stabilize the engine by disabling multi-threading. I set both graphics_vulkan_mt_display and graphics_vulkan_mt_smr to false. No change.
3. Peripheral Conflicts: Suspecting my Thrustmaster Hotas X might be causing jitter on the USB bus, I added a significant deadzone (7%) and even tried flying with the joystick completely disconnected using only the keyboard/mouse. The freeze still happens.
4. Display & Resolution: I tested in Fullscreen vs. Windowed mode. I also dropped the graphics_content_scale_factor to 0.75 and 0.85 to reduce VRAM load, but even with lower graphics, the freeze occurs at the exact same frequency.
5. External Hardware: I disconnected my external monitor (Alienware 32") and the USB-C adapter to rule out HDMI/DisplayPort clocking issues. I ran the sim purely on the MacBook's internal screen. It still froze.

Conclusion:
This isn't a "user setup" or a "scenery" issue. I’ve ruled out every possible external variable. The fact that the previous version (v4.8.1.1) ran perfectly on OpenGL suggests that the current MoltenVK/Vulkan implementation has a critical conflict with the AMD 5500M drivers on macOS Sequoia. It feels like a GPU watchdog timeout where the audio engine gets strangled by the graphics pipeline.

You have stated that this version supports older AMD-based Macs, but the reality is that the optimization for Intel/AMD hardware is currently broken. I have attached my main.mcf and the tm.log from the last hang. You will see I killed the process manually, but only because the sim was already completely frozen.

You need to focus your attention on the stability of the Vulkan pipeline for Intel Macs with AMD GPUs. The current build is not fit for purpose on this hardware, hence kindly look into this urgent matter.

Thank you in advance.

Quote from admin

@AeRodri Again, with all your repect, but you keep posting these over and over and keep making wrong statements.

Just for other users

• Aerofly FS 4 never used OpenGL on macOS
• There is no parameter like audio_buffer_size in our config files
• The user is still using lot's of user created 3rd pary content, where we have no control over which can cause all kind of issues.
• We have tested Aerofly FS on the same hardware and can fly for hours without any issues

Thanks for the reply.

If i continue to report these issues, it is because something is inherently not working and needs to be fixed. All i get as reply is that the user-content that i run is causing issues, which i believe is totally incorrect.

For the sake of that, i will run again tests today, without any user-content, to proof that there is an issue from 4.8.2.1 forward with the platform. I will post the results and logs here as soon as possible, after which i expect a more indepth investigation and a more careful reply.

I’ll keep this direct and factual. This next report comes from clean user testing after all instructions given were followed to the letter.

First, I am attaching a screenshot that clearly proves that all user-created content has now been completely removed.
There are no third-party airports, no custom scenery, and no residual files in the directories you mentioned.

I have re-tested extensively under strictly controlled conditions:

• Clean install of v4.8.2.1 on MacOS 15.7.5 (see specs in my signature below)
• No external monitor connected
• No joystick or external peripherals connected
• No USB devices at all
• Default aircraft only (including Q400 and others)
• Default scenery only
• Freshly generated main.mcf (created automatically on sim startup before the freeze)

Despite all of this, the exact same issue persists:

• Audio constantly degrades into a crackling loop.
• The audio suddenly, at a random point/interval, just cuts out entirely.
• The simulator instantly completely freezes, no movement possible.
• The application does not recover, and the only way out is for it to be force-quitted.

This behavior is 100% reproducible and independent of:

• Aircraft
• Location
• Weather
• Time of day
• Graphics settings

To be absolutely clear: this is happening on a clean, controlled environment with zero third-party influence, and occurs since v4.8.2.1 of AeroFly FS 4 on MacOS. In these last tests, no third-party monitors, no joystick, no hubs, no cables, no dongles, no NOTHING was used, just the MacBook Pro and a clean installation of the AeroFly FS 4 platform in its version v4.8.2.1.

Regarding the main.mcf: the file I am providing is not modified beyond basic testing, it is freshly generated by the sim on launch prior to the freeze. I am also attaching new log files from these clean tests, with no user content present. Also the SD folder was cleaned-out entirely, as per instructions from Jan, and you can see all new files in that folder were downloaded today upon starting a clean session.

At this point, the pattern is consistent and strongly suggests a core issue introduced in v4.8.2.1, likely related to the Vulkan/MoltenVK pipeline on Intel Macs with AMD GPUs. The symptoms (audio breakdown followed by a total system hang) remain identical across all test scenarios.

The previous version, at least up until v4.8.1.1, ran without these issues. The current version does not.

I’m not speculating for the sake of it, I’ve isolated variables as thoroughly as possible.
This needs to be investigated on the engine level rather than attributed to user setup.

Please review the attached logs from this clean state. Thank you in advance.

From the tm.log, I think this part might be interesting for you:

59.40-tmterrain: setting new terrain position: wg=((51555.70 32548.93)) global=((-1456788.98 6209132.67 -133067.32)) needtowait=1
59.93-tmterrain: done setting new terrain position: wg=((51555.70 32548.93)) global=((-1456788.98 6209132.67 -133067.32))
59.93-tmmodelmanager: moment masses 756.4 3254.4 509.7
59.94-module_map_render_aerial:init terrain flat renderer shared...
60.03-tmsimulator_recording: recording begin 9.38 mp=60549 mem=415MB
114.36-tmrenderer_vulkan: ERROR: Fatal : VkResult is 'ERROR_DEVICE_LOST' at line 12607
114.36-tmrenderer_vulkan:
114.36-tmrenderer_vulkan: ================================================================================
114.36-tmrenderer_vulkan: FATAL ERROR: vulkan crash message 'failed to submit draw commandbuffers'
114.36-tmrenderer_vulkan: memb=0 mema=1584 memt=2757MB memdl=0MB memdluse=0MB memdma=0 memdmt=0MB pl=56 pll=20 ds=102
114.36-tmrenderer_vulkan: ================================================================================
114.36-tmrenderer_vulkan:

Additionally, my second set of logs attached below shows a Fatal Device Lost at line 12607, just 234 seconds into the flight. Memory usage was only 2.2GB. The failure happens in the staging buffer fence (tp_sbch). This is a fundamental flaw in how your build v4.8.2.1 handles command submission on Intel/AMD hardware under macOS 15.7. It's not my hardware; it's your Vulkan implementation being incompatible with the current AMD drivers.

Hi,

What is the outcome of your investigation in this report so far, and what is the timeline for resolving this crash issue?

Thank you in advance.

Quote from admin

We are unable to reproduce the issue. We can fly on the same hardware for hours. No idea whats causing this on your side.

Has this been tested with the exact same AMD graphics card, a 2019 MacBook Pro with an Intel chip, and the latest Sequoia version (macOS 15.7.5)?

I strongly doubt that this issue with the Vulkan/MoltenVK pipeline on Intel Macs with AMD GPUs, which is not to blame to my personal setup, is affecting only my device, especially since I’m using a completely clean install from Steam.

What are your next steps and/or suggestions in the resolution process for this reported issue?

Sorry, but I'm afraid that I won't accept that default line for an answer or resolution. Something changed in the pipeline on your end after v4.8.1.1 of AFS 4, that is now suddenly, on a completely clean and virgin installation, causing constant crashes, and it's clearly your Vulkan implementation being incompatible with the current AMD drivers. I CAN run a complete v4.8.1.1 but anything after that I just crashing every 5-10 minutes for no reason.

I seek to encourage again the entire team a full and in-depth investigation on this matter for the sake of me being able to run v4.8.2.1 and later in a normal manner, just blaming the user's hardware when I clearly demonstrated that it's clearly your Vulkan implementation being incompatible with the current AMD drivers, is the lowest and most basic reply that one can get, with which I do not take comfort at all.

Kindly let me know if you need anything from my end, in terms of information, testing purposes, patch checking or anything else.
I will collaborate where needed and hence expect you to make every effort to fully understand, thoroughly investigate the case and do everything possible to get to the bottom of this issue.