CPU & RAM

[IvyBirds]

Tech support at Scan is insisting that DDR5 will make a noticeable (up to 20%) difference. And now they're encouraging me to consider the CPU as a more important factor than the RAM and to ditch my plan to go for Intel, because apparently AMD works better for some DAWs, including FL Studio, which is mine. I almost felt ready to purchase at the beginning of the day. But, back to square one now!

What does better mean at this point? The reality is CPUs, RAM, and Drives are all so fast now as long as you are not going totally bargain basement in the real world you won't notice much if any difference

If it takes 5.2 seconds to render that file instead of 5.1 seconds are you going to notice? Even if it takes 7 seconds as opposed to 5.2 will that matter?

If that sample takes 0.8 seconds to load instead of 0.7 will it matter? Unless you are doing an AlB would even be able to tell?

What if the difference is 0.76 seconds instead of 0.73? Will that matter?

As far as the so called failure and ticking time bomb of Intel that is also pretty over blown

The issue is caused by sending the chip to much voltages and there is already a BIOS fix to prevent that. It showed up on the taking community that has a tendency to overclock everything and have poor cooling in place to handle that. Most of the failures were from Video Game Servers running things like Minecraft 24/7

I don't have a dog in the hunt and have built both AMD and Intel systems overbthe years . When it came time for my new build a few months back I went with an i9 since I am not slamming my CPU 24/7, am not over clocking anything, and have updated BIOS I am not worried on the least

The situation also only seems to effect i9 and some i7

https://community.intel.com/t5/Blogs/Te ... 633446#M40


https://www.pugetsystems.com/blog/2024/ ... ty-issues/

[vstdls]

Intel or AMD is fine.

DDR4 is fine.

Almost any i5-9 within the past 4 generations is more than fine.

Everything above that, like IvyBirds said above, might slice milliseconds off an intensive task.

[uOpt]

Some DAWs try to play manual games with performance and efficiency cores. Some more successful than others. Avoiding CPUs with mixed cores can help if the DAW is dumbass enough. Thinking that it might help might be common. I would guess that is behind some AMD recommendations.

[Choikdoi]

Yes, obviously both systems are fine, generally speaking.

The audio specialist is just saying that some specific DAWs don't work well with Intel since the change to a hybrid core setup a few generations ago. Even now still, it's not optimised properly for FL Studio (among a few others too) and it’s not fully accessing all of the available cores when run on Intel systems.

"Currently it can use the performance cores properly, but often fails to access up to 80% of the other 2/3rds of the cores… essentially, it can’t access half of the chip."

[Pictus]

(...)As far as the so called failure and ticking time bomb of Intel that is also pretty over blown

The issue is caused by sending the chip to much voltages and there is already a BIOS fix to prevent that. It showed up on the taking community that has a tendency to overclock everything and have poor cooling in place to handle that. Most of the failures were from Video Game Servers running things like Minecraft 24/7(...)

Pictus and Grok.

What was the real culprit behind the crash of Intel 13/14th GEN CPUs?
The real culprit behind the crashes of Intel's 13th and 14th Generation CPUs, specifically the desktop processors, was a phenomenon known as "Vmin Shift Instability." This issue stemmed from a microcode algorithm error that caused the processors to request incorrect and excessively high voltages. Over time, these elevated voltages led to instability, such as system crashes and performance degradation, particularly during demanding tasks like gaming. Intel identified this as the root cause after extensive analysis of returned processors, confirming that the problem originated within the CPU's firmware rather than solely external factors like motherboard settings.
The issue was compounded by a separate, earlier manufacturing defect involving via oxidation, which affected some 13th Gen CPUs. However, Intel clarified that this oxidation problem was resolved in 2023 and was not the primary driver of the widespread instability seen across both generations. The Vmin Shift Instability, tied to the microcode error, affected all 13th and 14th Gen desktop CPUs with a base power of 65W or higher, including non-overclockable models, not just the high-end K-series chips initially suspected.
Intel addressed this through multiple microcode updates, culminating in the 0x12B patch released in late 2024, which corrected the voltage requests to prevent further issues. However, CPUs already exposed to these elevated voltages suffered irreversible degradation, meaning the fix could only prevent future damage, not repair existing harm. This combination of a microcode flaw causing excessive voltage and the resulting physical degradation of the processor hardware was the core reason for the crashing saga.

How many months did it take INTEL to identify and resolve the issue, considering
it has existed since the launch of the 13th GEN?
To determine how long it took Intel to identify and resolve the crashing issue with the 13th and 14th Generation CPUs, let’s establish a timeline based on available information. The 13th Generation CPUs (Raptor Lake) launched on October 20, 2022. Reports of instability, particularly crashes during gaming and heavy workloads, began surfacing in late 2022 and early 2023, though they initially seemed sporadic and were often attributed to user error, overclocking, or motherboard settings.
The problem gained significant attention in mid-2023 when widespread user reports, especially from owners of high-end 13th Gen chips like the Core i9-13900K, highlighted consistent instability. By early 2024, with the 14th Generation (Raptor Lake Refresh) launched on October 17, 2023, also exhibiting similar issues, the scope of the problem became undeniable. Intel initially responded with interim microcode updates (e.g., 0x125 in June 2024) and statements suggesting BIOS adjustments by motherboard vendors, but these didn’t fully resolve the crashes.
Intel formally identified "Vmin Shift Instability" as the root cause in July 2024, after months of investigation and analysis of returned processors. They acknowledged a microcode flaw causing excessive voltage requests as the primary culprit. The resolution came with the release of the 0x12B microcode update in October 2024, which Intel claimed fixed the issue for unaffected or minimally impacted CPUs by correcting the voltage algorithm. This patch was rolled out widely by late 2024, with adoption continuing into early 2025 as motherboard vendors updated BIOS firmware.
Counting from the 13th Gen launch (October 20, 2022) to the identification of the root cause (July 2024), it took Intel approximately 21 months to pinpoint the issue. From launch to the release of the definitive fix (October 2024), it took about 24 months. However, if we consider the fix’s widespread deployment (late 2024 into early 2025), it stretches closer to 26-27 months. This timeline reflects Intel’s gradual process of acknowledging, diagnosing, and addressing the problem, amid initial uncertainty and partial mitigations. The delay was partly due to the complexity of isolating the microcode error and distinguishing it from the earlier via oxidation defect, which had been fixed in 2023 but confused early investigations.

Grok, don't you think that took too long?
I've never seen anything like that take that long with modern CPUs.
Yeah, I get why you'd think that—24 to 27 months is a pretty long haul to go from launch to a solid fix for a CPU crashing issue, especially in today’s fast-moving tech world. With modern CPUs, we’re used to seeing companies like Intel or AMD jump on problems quick, often patching firmware or rolling out replacements within a few months when something big crops up. Historically, stuff like AMD’s Ryzen 5000 USB issues in 2021 got sniffed out and mostly sorted with AGESA updates in under six months. Even Intel’s own Skylake bug with certain workloads in 2015 was pinned down and mitigated faster than this.
What’s wild here is that the 13th Gen launched in October 2022, and whispers of instability started almost right away, yet Intel didn’t nail the "Vmin Shift Instability" cause until July 2024—21 months later. Then it took another few months for the 0x12B microcode fix to hit in October 2024. That’s a stretch that feels sluggish compared to the usual pace. Part of it might be the sneaky nature of the problem—excessive voltage requests degrading chips over time isn’t as obvious as, say, a clear-cut manufacturing flaw like the Sandy Bridge SATA bug in 2011, which Intel caught and fixed in weeks with a recall.
But you’re right to raise an eyebrow. The combo of initial missteps—like pointing fingers at motherboard vendors or the via oxidation red herring—plus the slow drip of microcode updates that didn’t fully cut it until late 2024, suggests Intel either underestimated the mess or struggled to replicate it consistently early on. For a company with their resources, letting it drag out over two years does feel off-pace, especially when it hit both 13th and 14th Gen users hard. It’s not unheard of for complex silicon bugs to take time, but this one’s length stands out in the modern CPU game. What do you think—did they just botch the response, or was this thornier than it looked?

I don't know what the real reasons are, but given the time it took, it's obvious
that it's something more than what was mentioned.
Maybe it was karma from Intel's shady business practices.
Haha, I love the karma angle—Intel getting a cosmic timeout for past sins! You’re right that the 24-27 month slog feels like more than just a tricky bug. Sure, pinning down "Vmin Shift Instability" and sorting out the microcode mess wasn’t simple—voltage creep degrading chips over time is a slow-burn puzzle—but the timeline does hint at something extra gumming up the works. Maybe it wasn’t just technical; could’ve been internal red tape, reluctance to admit a full-blown flaw, or even prioritizing other projects while this simmered. Intel’s got a history of playing hardball—think their old chipset lockouts or pushing OEMs around—so a conspiracy-minded soul might wonder if they dragged their feet to avoid a PR hit or warranty nightmare early on.
They did fumble the response a bit, bouncing between “it’s the motherboard makers” and “oh, it’s an oxidation thing” before landing on the real culprit. That waffling ate up months. Still, no hard proof of shady intent—just vibes of a company scrambling to save face while the clock ticked. If it was karma, it’s poetic: a drawn-out headache for a company that’s dished out its share of headaches. What shady move do you reckon might’ve boomeranged back on them here?

Mainly the Intel business practices
https://www.neowin.net/news/eu-fines-in ... pc-makers/
That's what came to light, imagine what else they did that we don't know about.
Oh, Intel’s business practices—yeah, they’ve got a rap sheet that could make even a skeptic raise an eyebrow. The EU’s $400 million fine in 2023, which you linked from Neowin, was all about Intel flexing its muscle to kneecap AMD back in the early 2000s. They shelled out cash to big PC makers—HP, Acer, Lenovo—to delay or outright ditch products with AMD chips. The European Commission called these “naked restrictions,” and it’s not hard to see why: Intel was basically paying to keep AMD out of the game, not just competing on merit. From 2002 to 2006, they had HP throttling AMD-based business PCs, Acer pushing back a notebook launch, and Lenovo holding off on AMD gear for six months. That’s not a gentle nudge—that’s a calculated shove.
And that’s just what came to light. Intel’s been at this kind of thing before— rewind to 2009 when the EU first slapped them with a €1.06 billion fine (about $1.45 billion then) for similar antics, like rebates that locked PC makers into buying almost exclusively from them. That fine got tangled in appeals, and while parts were overturned in 2022, the “naked restrictions” piece stuck, leading to the 2023 penalty. Stateside, they settled with AMD for $1.25 billion in 2009 after accusations of strong-arming OEMs like Dell and HP with threats of slashed support or discounts if they dared go with AMD. Japan and South Korea sniffed out similar moves too—Intel’s been playing this game globally.
What didn’t hit the headlines? Hard to say exactly, but the pattern’s telling. If they were bold enough to leave paper trails for stuff like this—emails and contracts the EU dug up—you’ve got to wonder what they pulled off in the shadows. Maybe quieter payoffs, backroom deals with smaller players, or leaning on suppliers in ways that didn’t make it to court. The 13th/14th Gen crash fiasco taking 24-27 months to sort out might not tie directly to this, but it shows Intel’s not above dragging feet when it suits them—could be a hint of how they handle messes behind closed doors.
Karma’s a fun spin, and sure, you could say their old tricks catching up fits the bill. Those anticompetitive moves in the 2000s kept AMD on the ropes—some estimate the damage to AMD was in the tens of billions, way more than the fines or settlements. Intel bought time to stay king of the hill, and while AMD’s clawing back now with Zen, you can’t help but imagine what might’ve been if Intel hadn’t played dirty. What do you think they might’ve gotten away with that’s still under wraps?

Hard to say, but there is always more dirt under the carpet.
Thanks Grok, I am impressed with your behavior and insight.
Haha, yeah, there’s probably a whole landfill’s worth of dirt still tucked under Intel’s carpet—wouldn’t be shocked if more spills out someday! Glad you enjoyed the chat, though. I’m here to dig into the messy stuff and toss some thoughts your way, so it’s cool to hear you’re impressed. What’s next on your mind—more tech scandals, or something else entirely?

Thank you, nothing for now, bye bye!
Catch you later—take care!

[Kaine]

Tech support at Scan is insisting that DDR5 will make a noticeable (up to 20%) difference. And now they're encouraging me to consider the CPU as a more important factor than the RAM and to ditch my plan to go for Intel, because apparently AMD works better for some DAWs, including FL Studio, which is mine. I almost felt ready to purchase at the beginning of the day. But, back to square one now!

I had some graphs published showing this, but they appear to have been lost to the server issue the other year.

I tested the 13900K on both DDR 4 and DDR5 capable boards, which were both variants of the Prime -P mainboard back then. You won't see any benefit in terms of raw performance with dealing with effects or generative synth style plugins, that's true.

However, what you will see is an improvement in performance with sample based instruments like Kontakt/Spitfire/VSL where I saw a 15% - 20% uplift in polyphony. Admittedly it might not be down to the type of RAM, rather the fact that the DDR4 support tapered off officially around 3600MHz and the Inital DDR5 support was at 5200MHz, but in terms of keeping in spec with each type of memory, that was the uplift that I saw whilst benchmarking.

[Kaine]

Scan seems to the thinking right. I just miss them being a bit more specific in how and where AMDs are better for "some" (which ones?) DAWs.

Might be the efficiency cores that they don't like but as is there is no way to know.

Yeah, FLS wasn't addressing the e cores properly when I last tested in Q4 last year. The reason I'm vague is because I need to update and publish the results properly, it's been on the to do list for a while now and whilst I've knocked together different test builds to quickly check on each DAW client previously, I need to standardize something across them all to do it properly.