You finally land the GPU you wanted. You cable-manage like an adult. You boot a game and—there it is: a thin, sharp squeal that rises and falls with the frame rate.
Your first instinct is “fan?” Your second is “I spent how much for this?”
Coil whine is one of those modern-PC problems that feels like a defect, behaves like a physics lecture, and is often “within spec” in the most emotionally unhelpful way possible.
This guide is how to treat it like an ops incident: identify the culprit, measure it, mitigate it, and decide when to return hardware versus when to move on with your life.
What coil whine actually is (and why it’s not just “noise”)
“Coil whine” is the audible vibration of power-delivery components under electrical load—most often inductors (chokes), sometimes transformers, occasionally ceramic capacitors via piezoelectric effects.
On a GPU, the usual suspects live in the VRM area: the circuitry that converts 12V from your PSU into the lower voltages the GPU core and memory actually use.
The key detail: the sound is a mechanical vibration driven by an electrical phenomenon. The GPU’s VRM switches current at high frequency. Magnetic fields change. Components experience forces. If something in that mechanical system resonates in or near the audible range—congratulations, you built a tiny speaker.
Coil whine is often most noticeable at very high frame rates, in menus, loading screens, or “uncapped FPS” scenarios where the GPU is producing frames as fast as it can, often with wildly varying instantaneous load.
It can also show up in non-gaming cases: scrolling in a browser, moving a window, or running certain compute workloads that create bursty power draw.
There’s an uncomfortable truth here: coil whine can happen on perfectly functional, within-spec hardware. It’s not a guaranteed indicator of imminent failure. It’s an indicator that your power electronics are excited in a way your ears don’t appreciate.
Where the sound comes from: GPU VRMs, inductors, and friends
The VRM as a noise generator
A GPU VRM is typically a multi-phase buck converter. Each “phase” has MOSFETs (switches), an inductor (choke), and capacitors to smooth current. The controller rapidly switches phases to maintain stable voltage under changing load.
The switching frequency can be hundreds of kilohertz to over a megahertz—well above hearing. So why do you hear it?
Because the electrical switching can excite subharmonics, transient bursts, and resonance in the component package and PCB. Also, mechanical vibration doesn’t need to match the switching frequency exactly; it needs to match some resonant mode that gets energy from that switching activity.
Why inductors get blamed (often correctly)
Inductors contain magnetic material. When current changes, magnetic forces can make the core or windings move. Manufacturers try to control this by:
potting (encapsulating) the coil in resin, using molded chokes, changing core materials, and tightening mechanical tolerances.
Still, small variations in assembly and materials mean two “identical” cards can behave differently.
Why the PSU is sometimes the villain (or an accomplice)
The PSU provides 12V, but not all 12V is created equal. Ripple, transient response, and the interaction between PSU regulation and GPU VRM behavior can change how hard the GPU VRM has to work.
That can shift the noise profile. Sometimes the squeal you think is “the GPU” is actually the PSU’s own coils under GPU load.
Case acoustics: your chassis is a soundboard
Airflow paths, panel stiffness, and even glass side panels can make coil whine more or less noticeable. A case with thin metal panels can amplify certain frequencies.
The GPU can be “normal,” and the case can be the amplifier.
Why it got more common: power density, high FPS, and modern loads
Coil whine isn’t new. What’s new is how many people can hear it and how often they hit the conditions that produce it.
- Power density went up. Modern GPUs pull serious power through compact VRMs. Higher currents mean stronger forces.
- FPS went up. High-refresh monitors and “uncap everything” culture produce very high FPS in menus and esports titles.
- Loads are burstier. Modern rendering pipelines and boost algorithms create fast-changing power draw, which can excite resonance.
- PCs got quieter. When your fans idle at 500–800 RPM, you suddenly notice everything else.
Here’s the operational framing: coil whine is a human-perception problem driven by electromechanical behavior. Fixing it is partly engineering, partly expectation management.
Fast diagnosis playbook (first/second/third)
If you want the quickest path to “is this fixable, tolerable, or returnable,” do this in order. Don’t start by disassembling anything. Don’t start by buying a new PSU. You’re not on a shopping quest; you’re on an incident call.
First: confirm it’s not a fan, cable, or loose panel
- Stop the GPU fans briefly (software “0 RPM” mode, or set a temporary low curve—don’t jam fingers into fans). If the noise persists unchanged, it’s not fan bearing noise.
- Open the case side panel. If the noise changes dramatically, you may be dealing with panel resonance amplifying a normal level of whine.
- Check for a cable touching a fan. This sounds dumb until it ruins your evening.
Second: correlate the noise with FPS and GPU power
- Cap FPS to 60/120/144 and see if the noise drops. Coil whine that tracks FPS is classic.
- Undervolt slightly and test again. Reduced voltage often reduces whine by reducing current and changing switching behavior.
- Change load type (game menu vs benchmark vs compute). If it only happens in menus, it’s likely high-FPS transient behavior.
Third: isolate GPU vs PSU vs motherboard
- Swap the PSU only if you can borrow one known-good. Otherwise, you’re guessing with money.
- Move the GPU to another system if possible. Same noise follows the GPU? GPU is the source. Noise changes drastically? Interaction effect.
- Listen near the PSU exhaust vs near the GPU VRM area. It’s crude but effective.
You’re looking for repeatability. A reliable reproduction is 80% of debugging.
Hands-on tasks: 12+ real checks with commands, outputs, and decisions
These tasks assume Linux because it’s where we can show real, inspectable telemetry without vendor GUIs. If you’re on Windows, the logic still applies; you’ll just use different tools.
The point is not the exact command—it’s the discipline: measure, interpret, decide.
Task 1: Identify the GPU and driver (baseline your environment)
cr0x@server:~$ lspci -nn | grep -Ei 'vga|3d|display'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation AD104 [GeForce RTX 4070] [10de:2786] (rev a1)
What it means: You’ve confirmed the device model and PCI location (01:00.0). Useful when you have multiple GPUs.
Decision: If you don’t see the expected GPU, stop. You’re troubleshooting the wrong machine—or the iGPU is active.
Task 2: Watch GPU power draw and clocks during the noise
cr0x@server:~$ nvidia-smi --query-gpu=timestamp,power.draw,clocks.gr,clocks.mem,utilization.gpu --format=csv -l 1
timestamp, power.draw [W], clocks.gr [MHz], clocks.mem [MHz], utilization.gpu [%]
2026/01/21 10:11:01, 38.52 W, 2100 MHz, 8101 MHz, 12 %
2026/01/21 10:11:02, 224.31 W, 2730 MHz, 10001 MHz, 98 %
What it means: You can correlate a squeal to a power spike or sustained high power.
Decision: If whine appears primarily during rapid power changes (spiky behavior), FPS limiting and smoothing frame pacing are your first mitigations.
Task 3: Confirm whether FPS is the trigger (cap it)
cr0x@server:~$ mangohud --dlsym ./your_game_binary
MangoHud: F12 toggles HUD, FPS limit: 0
What it means: MangoHud is injecting and can apply an FPS limiter (configuration or hotkeys, depending on setup).
Decision: If coil whine vanishes when you cap FPS to your monitor refresh (or slightly below), stop hunting ghosts. Your fix is an FPS cap, not an RMA.
Task 4: Verify the kernel sees coil-related power management events (PCIe link changes)
cr0x@server:~$ lspci -s 01:00.0 -vv | grep -E 'LnkSta|LnkCap'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s (ok), Width x16 (ok)
What it means: You’re verifying PCIe link speed/width is stable. Power-state flapping can change load characteristics.
Decision: If link speed is unexpectedly low or unstable, fix that first (BIOS/slot/risers). Don’t blame coil whine for a degraded system.
Task 5: Check CPU power management changes (sometimes it’s not the GPU)
cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
What it means: A “powersave” governor can cause frame-time jitter; jitter can cause bursty GPU load, which can worsen whine.
Decision: For testing, switch to performance and see if the noise profile changes. If it does, you’re dealing with load transients.
Task 6: Temporarily set CPU governor to performance (test, don’t marry it)
cr0x@server:~$ sudo apt-get update -y && sudo apt-get install -y linux-tools-common linux-tools-generic
Reading package lists... Done
Setting up linux-tools-common ...
Setting up linux-tools-6.8.0-xx-generic ...
cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
What it means: CPU will respond faster; fewer dips and spikes.
Decision: If coil whine reduces, you’ve learned something: smoothing system behavior can reduce VRM excitation. Now decide whether to tune power policies or just cap FPS.
Task 7: Confirm the noise isn’t from the PSU (load it and listen)
cr0x@server:~$ stress-ng --cpu 8 --cpu-method matrixprod --timeout 30s --metrics-brief
stress-ng: info: [23144] dispatching hogs: 8 cpu
stress-ng: metrc: [23144] cpu 30.00s 2400.00 bogo ops/s
What it means: This loads CPU, not GPU. If the “coil whine” happens under CPU-only load, your PSU or motherboard VRM may be the source.
Decision: If the noise appears without GPU load, stop tuning GPU settings. Investigate PSU/motherboard VRM, and check for loose panels.
Task 8: Load the GPU in a repeatable way (controlled reproduction)
cr0x@server:~$ sudo apt-get install -y glmark2
Reading package lists... Done
Setting up glmark2 ...
cr0x@server:~$ glmark2 --fullscreen
=======================================================
glmark2 2023.01
=======================================================
[build] use-vbo=false: FPS: 3920 FrameTime: 0.255 ms
What it means: Very high FPS tests often trigger whine. Menus do this too; benchmarks make it repeatable.
Decision: If whine is loud here but disappears when you cap FPS, you have a clear mitigation path: cap it.
Task 9: Cap FPS at the compositor level (Wayland/X11 test)
cr0x@server:~$ sudo sed -i 's/^#\?MaxFPS=.*/MaxFPS=144/' /etc/environment
sed: can't read /etc/environment: No such file or directory
What it means: Not all systems expose a single global FPS cap, and random internet tweaks often don’t apply. Good: you just avoided wasting time.
Decision: Use per-game FPS caps (engine settings, MangoHud, driver control panel) rather than chasing mythical “one file to cap them all.”
Task 10: Check PSU rails and sensors (only for hints, not gospel)
cr0x@server:~$ sudo apt-get install -y lm-sensors && sudo sensors-detect --auto
Found `coretemp` sensor, loading...
Found `nct6775` sensor, loading...
cr0x@server:~$ sensors
nct6775-isa-0290
Vcore: 1.056 V
+12V: 12.096 V
+5V: 5.040 V
What it means: Motherboard sensors are approximate. They won’t show ripple and fast transients.
Decision: If 12V is wildly off-spec (rare), investigate PSU. Otherwise, don’t over-interpret. Coil whine can happen on perfect 12V readings.
Task 11: Check dmesg for PCIe or power errors (rule out real faults)
cr0x@server:~$ dmesg -T | grep -Ei 'pcie|aer|nvrm|amdgpu|xid' | tail -n 10
[Tue Jan 21 10:09:33 2026] NVRM: GPU 0000:01:00.0: RmInitAdapter succeeded
What it means: You’re checking that you don’t have actual hardware instability masquerading as “just noise.”
Decision: If you see AER errors, Xid errors, or GPU resets, stop treating this as coil whine. You may have a failing GPU/PSU/PCIe path.
Task 12: Verify you’re not overheating and hitting power/clock oscillation
cr0x@server:~$ nvidia-smi --query-gpu=temperature.gpu,clocks.gr,pstate,clocks_throttle_reasons.active --format=csv
temperature.gpu [C], clocks.gr [MHz], pstate, clocks_throttle_reasons.active
71, 2685, P2, Not Active
What it means: If you’re thermally or power throttling, the GPU may oscillate between states, changing VRM behavior and sometimes changing whine tone.
Decision: If throttling is active, fix cooling/power limits first. Whine mitigation works better on a stable operating point.
Task 13: Create a controlled A/B test with power limit (NVIDIA example)
cr0x@server:~$ sudo nvidia-smi -pl 200
Power limit for GPU 00000000:01:00.0 was set to 200.00 W from 220.00 W.
What it means: Lowering power limit reduces current and can reduce whine (and heat) with minimal performance loss depending on the card.
Decision: If whine drops significantly and performance impact is acceptable, keep the limit. If not, revert and try undervolting or FPS caps.
Task 14: Check whether the noise only happens at idle/2D clocks (desktop whine)
cr0x@server:~$ nvidia-smi --query-gpu=clocks.gr,clocks.mem,pstate --format=csv -l 1
clocks.gr [MHz], clocks.mem [MHz], pstate
210, 405, P8
2100, 8101, P2
What it means: Some systems whine during state transitions (P8 to P2), like when you scroll a heavy webpage or the compositor spikes.
Decision: If desktop transitions trigger whine, you can test forcing a consistent power state (where supported) or reduce transient triggers (browser hardware acceleration settings, refresh rate changes). But don’t force max clocks 24/7 unless you like heat.
Task 15: Validate your audio isn’t lying (ground loop confusion)
cr0x@server:~$ pactl list short sinks
0 alsa_output.pci-0000_0b_00.4.analog-stereo PulseAudio s16le 2ch 44100Hz RUNNING
What it means: Some people chase “coil whine” that’s actually interference in audio output, especially with front-panel audio.
Decision: If the noise is in headphones/speakers (not audible from the case), investigate audio grounding/shielding and try rear I/O or USB audio.
What you can do: mitigations that work (and what’s placebo)
1) Cap FPS (the boring fix that actually works)
Coil whine loves uncapped FPS because the GPU is sprinting with little real-world benefit. Your monitor cannot display 3000 FPS in a menu. Your GPU can, and it will complain loudly while doing it.
Cap FPS in-game, via driver control panel, or via an overlay limiter. Aim for:
your refresh rate, or slightly below (e.g., 141 on a 144 Hz panel) to reduce oscillation.
2) Enable V-Sync (or adaptive sync + a cap)
V-Sync limits FPS by syncing to refresh, which often eliminates the highest-FPS scenarios that trigger whine. The downside is input lag in some titles.
A more modern approach: use VRR (G-Sync/FreeSync) plus an FPS cap just below refresh.
3) Undervolt (best “engineering” fix for many cards)
Undervolting reduces current for the same workload, and it can shift the VRM’s operating point away from a resonant condition.
It’s not guaranteed, but it’s one of the few mitigations that can reduce whine without sacrificing much performance.
Do it carefully. Step down voltage in small increments, stability-test, and monitor for driver resets. You’re not trying to win an undervolt competition; you’re trying to stop the screaming.
4) Lower the power limit (often “good enough”)
Power limiting is undervolting’s simpler cousin. It’s blunt, but predictable.
Many GPUs lose little real FPS by dropping 5–10% power, especially if they were running into diminishing returns.
5) Change the load profile (menu fixes)
If whine happens in menus or loading screens: set menu FPS caps if the game supports it.
Some engines let menus render at infinite FPS by default because nobody asked the UI to behave like a responsible adult.
6) Case and placement tweaks (acoustic mitigation)
If the whine is “barely there” but annoying, a few physical changes can help:
- Move the case off the desk and onto the floor (less direct line-of-sight to your ears).
- Add a bit of distance or rotate the case so the GPU side panel isn’t aimed at you.
- Tighten panels and PCIe bracket screws; resonance is a real amplifier.
- Add mild damping (better panels, not stuffing foam into airflow paths like you’re soundproofing a jet engine).
7) Try a different PSU (only as a controlled experiment)
A PSU swap is not a first-line fix because it’s expensive and uncertain. But interaction effects are real:
a different PSU’s transient response and ripple characteristics can change GPU VRM behavior.
The sane method: borrow a known-good PSU with sufficient capacity and quality, test it for 30 minutes under the same workload, then decide.
Joke #1: If your GPU sings at 3 kHz only in the main menu, congratulations—you bought a very expensive instrument that only knows one song.
What you can’t do (without becoming the problem)
You can’t “fix” it with driver updates in most cases
Drivers can change boosting behavior, frame pacing, and power management defaults. That can shift when whine happens.
But if the root cause is a mechanical resonance in an inductor, software can only avoid the trigger conditions, not remove the physical capability to vibrate.
You can’t safely “glue the coils” unless you’re a rework tech
People love the idea of adding epoxy or hot glue to damp vibration. Sometimes manufacturers do use potting compounds.
But doing it yourself on a modern GPU is high-risk:
- You can trap heat in the VRM area.
- You can contaminate components or short pads if you use the wrong material.
- You can void warranty and reduce resale value instantly.
Unless you’re comfortable doing board-level rework and accept the consequences, don’t. “I watched a video” is not a qualification.
You can’t treat it as a reliability metric
Coil whine is not, by itself, evidence the GPU is failing. Some cards whine on day one and run for years. Some are silent and still die from unrelated causes.
If you have errors, crashes, black screens, or AER spam—different incident, different playbook.
Common mistakes: symptom → root cause → fix
1) “It’s a grinding noise, must be coil whine”
Symptom: Rough, low-frequency grinding that changes with fan speed.
Root cause: Fan bearing, cable rub, or a bad fan curve causing constant ramping.
Fix: Stop/slow fans briefly to confirm; reroute cables; adjust fan hysteresis; replace fan if bearing is shot.
2) “It only happens in menus, so something is broken”
Symptom: Loud squeal in menus/loading screens, quieter in gameplay.
Root cause: Uncapped FPS in low-complexity scenes causing extreme FPS and bursty power draw.
Fix: Set menu FPS cap or global cap; enable V-Sync/VRR with cap slightly below refresh.
3) “New PSU didn’t fix it, so the GPU is defective”
Symptom: Coil whine unchanged after PSU swap.
Root cause: The GPU’s VRM resonance dominates; PSU interaction was not the main factor.
Fix: Use FPS caps/undervolt; consider RMA only if it’s unusually loud and the vendor accepts noise complaints.
4) “I undervolted and now it whines more”
Symptom: New or shifted whine tone after undervolt.
Root cause: You moved the VRM into a different operating region; resonance changed.
Fix: Try a different voltage/frequency point; sometimes a slightly higher voltage reduces whine by changing switching behavior. Test systematically.
5) “It’s coil whine, ignore the crashes”
Symptom: Noise plus driver resets, black screens, or PCIe/AER errors.
Root cause: Actual instability: power delivery, overheating, bad cable/connector, riser issues, or defective hardware.
Fix: Treat as a stability incident. Check logs, cabling, thermals, power limits; revert overclocks; test in another system; RMA if reproducible.
6) “It’s in my headphones, so the GPU is whining”
Symptom: High-pitched noise in audio that changes with GPU load.
Root cause: EMI/grounding issue in audio path, especially front-panel audio or poorly shielded cables.
Fix: Use rear audio out; try USB DAC; reroute audio cables away from GPU power; check grounding.
Three corporate mini-stories from the trenches
Mini-story 1: The incident caused by a wrong assumption
A media pipeline team rolled out new GPU nodes for transcoding. Within a day, tickets landed: “Some servers are squealing,” “Maybe the GPUs are failing,” “We should pull them before they die.”
The environment was a shared office space adjacent to the rack room. Humans were now part of the monitoring stack.
The wrong assumption was simple: audible noise equals impending failure. Someone correlated the squeal with a few job retries and decided the cards were flaking out.
A rollback was proposed. Procurement was looped in. The mood turned expensive fast.
We did the unsexy thing: split the problem into two signals—acoustic noise and compute errors.
Logs showed no ECC issues, no Xid storms, no PCIe AER spam. GPU temps were stable. Power draw was stable during jobs.
The retries were traced to a storage-side timeout unrelated to GPUs.
Then we reproduced the squeal on demand: it happened when the job scheduler was idle and a health check rendered a lightweight GPU “test frame” loop at extremely high FPS.
Under real transcode load, the GPUs were quieter because the workload produced steadier power draw.
The fix wasn’t hardware. We capped the health check’s render loop and reduced its polling frequency.
The room got quieter, the GPUs kept working, and everyone got to keep their weekend.
Mini-story 2: The optimization that backfired
A visualization team wanted lower latency in an interactive app. They disabled V-Sync, removed frame caps, and configured the renderer to “always run as fast as possible.”
The benchmark graphs improved. The UX felt snappier. Everyone high-fived, as engineers do when a line goes up.
Then complaints started: “Workstations are screaming,” “It’s distracting,” “Are we damaging the GPUs?”
People began limiting sessions because the noise was irritating in an open-plan office. Productivity became an acoustic casualty.
We instrumented it. The app’s idle screen was pushing absurd FPS—thousands—because the scene complexity was near-zero and the GPU boost algorithm happily obliged.
That created the perfect coil whine trigger: extremely high switching activity with fast-changing load at the edge of what the VRM wanted to do quietly.
The “optimization” was actually waste. Those extra frames were not visible and not improving meaningful latency.
The fix: cap FPS at the display refresh rate for idle and menus, allow higher FPS only during specific interaction modes where it mattered, and keep VRR enabled.
Performance stayed good where it counted. Noise dropped. The real lesson: uncapped rendering is a power virus that also happens to squeal.
Mini-story 3: The boring but correct practice that saved the day
In a data science group, a batch of new GPU workstations arrived. A few units had noticeable coil whine under certain workloads.
The knee-jerk response was to RMA everything that made a sound. That would’ve taken weeks and created a spare-parts mess.
The team had a boring practice: a standardized acceptance test and a written “known-good baseline” for each machine.
That baseline included logs under load, temps, power draw, and a quick acoustic check under a standardized benchmark with FPS capped and uncapped.
With that baseline, we separated “annoying but stable” from “noisy and unstable.”
Two machines showed PCIe AER errors under load and occasional GPU resets. Those went straight to hardware remediation.
The noisy-but-stable ones were mitigated with a documented per-profile cap and mild power limit reduction.
The practice that saved the day wasn’t a magic fix. It was having evidence.
We avoided mass RMAs, focused on the actual faulty units, and shipped a consistent configuration that kept the office livable.
Interesting facts and historical context
- Coil whine predates GPUs. Early switch-mode power supplies in consumer electronics were notorious for audible squeal under certain loads.
- “Quiet computing” made it more obvious. As fans got larger and slower, background noise dropped—and coil whine became easier to hear.
- High FPS can be louder than high load. Menus can trigger more whine than gameplay because the GPU hits extreme FPS with rapid load variation.
- Manufacturers already try to prevent it. Molded chokes and potting compounds exist largely to reduce vibration and audible noise.
- Two identical cards can sound different. Minor variation in inductor core material, winding tension, or PCB stiffness changes resonance.
- PSU and GPU can “couple.” The interaction of PSU ripple/transient response with GPU VRM behavior can change whine intensity and pitch.
- Coil whine can change over time. Thermal cycling can slightly alter mechanical fit; some units get quieter, some don’t.
- It’s not always the GPU. Motherboard VRMs and PSUs can whine under GPU-induced load changes, confusing diagnosis.
- Not all whine is audible to everyone. Frequency content can sit where younger ears hear it clearly and older ears barely notice it—leading to “it’s fine” arguments at home or in offices.
What coil whine tells you about your system (and what it doesn’t)
Coil whine is a hint about how your system behaves electrically. It can tell you:
“Your GPU is running uncapped and hitting silly FPS,” or “Your load is bursty,” or “Your case is amplifying a tone.”
It does not tell you the GPU is dying.
To borrow a paraphrased idea from W. Edwards Deming: without data, you’re just someone with an opinion. That applies to PC noise too.
Checklists / step-by-step plan
Checklist A: 15-minute triage (don’t buy anything yet)
- Confirm it’s not a fan or a cable rubbing.
- Open the case panel and see if the sound changes (acoustic amplification check).
- Reproduce in a menu or benchmark reliably.
- Cap FPS to your monitor refresh; retest.
- Enable V-Sync/VRR; retest.
- Check logs for errors (AER/Xid/amdgpu faults). If errors exist, treat as stability issue.
Checklist B: Mitigation ladder (stop when you’re satisfied)
- FPS cap (per-game or global).
- Menu FPS cap (if the game supports it).
- Power limit -5% to -10% and retest.
- Undervolt with stability tests.
- Case acoustics: tighten panels, reposition, mild damping.
- PSU A/B test (borrow one) to see if interaction changes the tone.
- RMA decision if it’s objectively loud and bothersome under normal capped gameplay.
Checklist C: RMA decision rubric (practical, not emotional)
- RMA-friendly: loud whine at normal capped FPS, audible across the room, repeatable across multiple PSUs/systems, within return window.
- Probably keep: only loud in uncapped menus/benchmarks; disappears with cap; no stability issues.
- Not negotiable: any resets, artifacts, crashes, or AER/Xid logs—return/repair for stability, not for noise.
Joke #2: Coil whine is the only performance metric your ears can benchmark, and it has terrible documentation.
FAQ
1) Is coil whine a defect?
Sometimes. Often it’s “within spec.” If it’s loud under normal use (capped FPS, typical workloads) and bothers you, treat it as a quality defect and return it if your vendor allows.
2) Does coil whine damage the GPU?
Generally, no. It’s vibration, not inherently destructive. But if the noise comes with instability (crashes, errors), that’s a separate problem that can indicate real electrical or thermal issues.
3) Why is it loudest in game menus?
Menus can render at extremely high FPS because they’re simple scenes. That can create bursty power draw and excite resonances in the VRM components.
Cap menu FPS or enable V-Sync.
4) Why did it start after a driver update?
Drivers can change boost behavior, frame pacing, and power management. That can move the GPU into a different operating region that triggers whine more often.
It doesn’t mean the driver “caused” a physical defect; it changed the conditions.
5) Can a different PSU fix it?
Sometimes, yes—especially if the current PSU has poor transient response or the interaction creates an audible resonance. But it’s not guaranteed.
Test with a borrowed known-good PSU before spending money.
6) Will undervolting always reduce coil whine?
No. It often helps, but it can also shift the pitch or even make it worse if you land on a resonance. Undervolt in steps and A/B test with the same workload.
7) Is coil whine covered by warranty?
It depends on the vendor and region. Many vendors treat it as cosmetic unless it’s extreme. Retailer return windows are often the most practical path if you can’t tolerate it.
8) Can I “burn in” the card to make it go away?
Sometimes the sound changes after thermal cycling, but counting on burn-in is gambling. If it bothers you and you’re within return window, decide early.
9) Why do some people not hear it?
Coil whine can sit at frequencies some people perceive more strongly than others. Also, case placement and ambient noise matter. Quiet room, case on desk, side panel facing you—maximum annoyance.
10) What’s the difference between coil whine and electrical buzzing in speakers?
Coil whine is acoustic noise from components in the PC. Buzzing in speakers/headphones is often EMI or grounding issues in the audio path.
If you can’t hear it from the case but hear it in audio, troubleshoot audio routing/shielding instead.
Practical next steps
Treat coil whine like any other production annoyance: measure first, change one variable at a time, and stop when the pain is gone.
Start with the easy wins: cap FPS (especially menus), enable VRR/V-Sync where appropriate, and try a modest power limit reduction.
If it’s still loud under normal use and you’re inside the return window, return it. Life is short and your ears don’t have a “mute VRM” button.
If you do nothing else, do this: reproduce the noise reliably, cap FPS to sane numbers, and verify you have no stability errors in logs.
That turns “my GPU is screaming” into “my GPU is fine, my settings were rude.”