Kali VirtualBox No Sound After Update: Intel HD Audio vs ICH AC97 Fix + PipeWire Restart (Fast Checklist)

---

No Sound snapshot: what broke (and what didn’t)

When audio dies “right after an update,” your brain wants a single villain. In practice, VirtualBox audio is a chain: VirtualBox emulates a sound card → Kali’s audio stack (PipeWire/WirePlumber or PulseAudio) exposes devices/sinks → your desktop session routes sound to a sink. The chain only needs one weak link to go silent.

No devices vs device present but silent (choose your lane)

Start by labeling the symptom. It saves you 20 minutes of wandering:

• Lane A: “No output devices” / “Dummy Output only” — Kali isn’t seeing (or selecting) a usable sink. This often points to the controller choice, a service that didn’t come up cleanly, or routing got stuck.
• Lane B: Device exists, but it’s silent — the virtual device is present, but audio is muted, routed to the wrong sink, or the service is wedged.

Host audio OK, VM silent — the most likely root causes

If your host can play YouTube but Kali can’t, that’s a quiet gift: it suggests your OS audio stack is fine. Most “VM-only silence” is one of these:

• VirtualBox controller mismatch (Intel HD Audio vs ICH AC97).
• Wrong VirtualBox host audio backend/driver selected.
• PipeWire/WirePlumber in your Kali session stuck after package changes.
• Sink routing flipped to HDMI/Dummy Output after update.

Curiosity gap: Why an apt upgrade can change audio without touching VirtualBox

Because the update didn’t change VirtualBox—it changed the glue inside Kali. Audio is not “one package.” It’s services, session managers, compatibility layers, and per-user config. A small change (like a service restart, a new WirePlumber policy, or a user config override) can alter device selection behavior even when VirtualBox settings stay identical.

Personal note: The first time this happened to me, I reinstalled a whole VM… and felt heroic for 10 minutes… until it happened again next update. The second time, I did the chain test and fixed it in under 6 minutes. The difference was not intelligence. It was refusing to panic.

Triage first: the 60-second “don’t-reinstall” checklist

This is the “I have a meeting in 12 minutes” section. Do these in order. Don’t improvise. (Improvisation is how you end up with five tabs open and zero sound.)

Confirm VirtualBox Audio enabled + correct host output device

• Power off the VM (not saved state), open VirtualBox settings for the VM, and verify Audio is enabled.
• If VirtualBox shows an option for input/output toggles, confirm output is enabled.
• If your host has multiple outputs (speakers + Bluetooth + HDMI), set your host’s preferred output before starting the VM. VirtualBox follows the host chain.

Confirm Kali volume + app volume + output device isn’t muted

• In Kali, open the sound panel and verify output volume is not muted.
• If your desktop has per-app volume (common), confirm the app you’re testing isn’t at 0%.
• Test with one “known-noisy” source: a system sound, a browser tab, or a simple audio test file.

Let’s be honest… you’re one toggle away from fixing it

I’ve watched this exact issue “resolve” because the VM was in a saved state and VirtualBox didn’t renegotiate audio cleanly. If you’re currently using saved states like emotional support blankets, do a full shutdown once. It’s boring. It’s also effective.

Controller choice: Intel HD Audio vs ICH AC97 (the fork that matters)

This is the moment most guides skip because it’s not glamorous. But it’s where a big chunk of “no sound after update” issues end. VirtualBox offers multiple emulated audio controllers, and Kali’s stack can behave differently depending on which one you present to the guest.

Intel HD Audio when you want modern behavior (and when it fails)

Intel HD Audio is the “newer” choice and often works well—until it doesn’t. If audio disappeared after a system update (especially one that touched PipeWire/WirePlumber), Intel HD Audio can end up being the controller that exposes the bug. Symptoms often look like:

• Output device appears, but sound is silent.
• Only “Dummy Output” appears intermittently.
• Restarting audio services helps once, then the problem returns.

ICH AC97 when compatibility wins (older, but stubbornly reliable)

ICH AC97 is the “older” controller, and that’s exactly why it can save you. Many Linux guests behave more predictably with AC97 because the emulation has been stable for a long time. If you want the quickest “make it work again” test, switching to ICH AC97 is often the cleanest move.

SoundBlaster 16 — what it’s actually for (rare, but useful)

SoundBlaster 16 is mainly a compatibility tool for older setups. It’s not the first pick for modern desktops, but it can be a useful “third option” if you’re in a weird edge case. Treat it as a diagnostic lever, not a lifestyle.

Curiosity gap: Why controller swaps “fix” sound without changing Kali at all

Because you changed what Kali thinks the hardware is. The guest doesn’t know it’s virtual. When you swap controllers, you force a clean re-detection path: new device ID, new driver binding, new default sink selection. That resets a surprising amount of “sticky” state.

Show me the nerdy details

VirtualBox emulates different audio devices (controllers). The guest OS loads different kernel drivers and user-space routing policies based on the detected device. When your audio stack updates, policy and compatibility layers can change how devices are prioritized or exposed to the desktop session. Swapping controllers is a controlled way to force a re-bind and re-route without reinstalling anything.

VirtualBox audio settings: the quiet killers (driver, I/O, passthrough)

If controller choice didn’t instantly fix it, the next suspect is the VirtualBox host audio configuration. Oracle’s VirtualBox documentation describes multiple host audio drivers/backends depending on your host OS (Windows, macOS, Linux). That matters because VirtualBox isn’t just “passing audio through.” It’s translating audio between host and guest worlds.

Host driver pick (Windows/macOS/Linux): why defaults sometimes break

• Windows hosts: you may see options like WASAPI or DirectSound depending on VirtualBox version. If audio broke after host updates, switching the host audio driver can restore stability.
• macOS hosts: CoreAudio is typical. If you’re using Bluetooth devices heavily, test once with wired output to isolate host device switching issues.
• Linux hosts: you may see ALSA or PulseAudio options. If your host uses PipeWire, the “PulseAudio” backend often remains relevant because PipeWire provides compatibility layers.

Audio I/O toggles: what “enabled” still gets wrong

In VirtualBox settings, audio can be enabled while output (or input) is effectively disabled by a secondary toggle. If you never use a VM microphone, you can keep input off—but verify output is on. (And if you’re testing a “no sound” issue, don’t let input troubleshooting distract you.)

USB headset/dongle passthrough: the “it worked yesterday” trap

USB audio passthrough is a different beast: you’re no longer using VirtualBox’s emulated sound card—you’re passing a physical device into the guest. That can work beautifully… until the host grabs the device first, or the device changes its profile (common with headsets). If you’re in a hurry, disable passthrough and test using the emulated controller first. Prove the basics, then reintroduce USB complexity. (If you’re building portable labs, Kali persistent USB setups with Secure Boot can add their own audio quirks—treat those as a separate track.)

Here’s what no one tells you… host driver is part of the chain

A surprising number of “Kali audio broke” moments are really “host audio backend + VM audio negotiation broke.” That’s why the best troubleshooting is boring: isolate one link at a time. If you’re doing broader VM tuning at the same time, keep your networking mode stable too—NAT vs bridged changes can stack confusion fast, so it helps to already know how VirtualBox NAT/Host-Only/Bridged actually differs before you start changing multiple systems at once.

Personal note: I once chased “Kali audio bugs” for an hour before noticing my host had switched output to a monitor that wasn’t even on. I tell you this so you don’t have to become me.

PipeWire reset: restart the stack (no reboot, no drama)

Modern Linux desktops commonly route audio through PipeWire with a session manager like WirePlumber, while still offering PulseAudio-compatible interfaces for apps. After updates, user services can get stuck in a half-alive state. Restarting them is safe, fast, and reversible. (This same “update drift” pattern shows up in other Kali tools too—if you’ve ever had Metasploit break after rolling updates, you’ll recognize the vibe in Kali msfconsole Bundler/Ruby version mismatch fixes.)

Quick check: are you on PipeWire/WirePlumber or PulseAudio?

If you’re not sure, don’t overthink it—use quick “what’s running” checks. The goal is not to become an audio scholar; it’s to confirm the service layer exists and is active in your user session.

Restart steps + what “success” looks like (device appears + sink active)

Try these in a terminal inside Kali (user session). If one command errors, move to the next—errors can be useful signals, not disasters.

# Restart PipeWire + session manager (WirePlumber)
systemctl --user restart pipewire
systemctl --user restart wireplumber

# If your distro uses pipewire-pulse compatibility
systemctl --user restart pipewire-pulse

# Check status quickly
systemctl --user --no-pager --full status pipewire wireplumber pipewire-pulse

What success looks like:

• Your sound settings show a real output device (not only Dummy Output).
• Playing audio changes the volume meter or shows activity.
• Reboot is no longer required to “wake” audio.

Curiosity gap: Restart works once—then fails again… what autostart clue you missed

If restarting fixes it but the next boot breaks it again, that’s usually not “random.” It’s often a user config override or a session manager policy issue. Sometimes old per-user audio config files linger and override new defaults. The fix is usually: identify the config causing the override, then reset it—carefully. (Don’t delete things blindly; rename and test.)

Show me the nerdy details

Audio services often run as user-level systemd units. After package updates, unit files and compatibility sockets can change behavior. Restarting the user units forces a clean reload of service state and reconnects client apps to the audio server. If the issue returns after reboot, it can be caused by per-user configuration that persists across package changes.

Short Story: The first time I saw “Dummy Output” in a VM, I treated it like a verdict. I Googled until my browser tabs looked like a paper fan. Then I did the simplest thing: restarted PipeWire and WirePlumber. Sound returned instantly—like it had been waiting behind a curtain the whole time.

I felt relieved, then annoyed, because the fix was so ordinary. But that’s the point: most VM audio problems aren’t epic. They’re small state glitches wearing a dramatic costume. And once you’ve seen it once, you stop feeding it your entire afternoon.

Sink routing: when sound “plays” to nowhere (Dummy Output, HDMI, wrong default)

This is the sneakiest failure mode because it looks like everything is “working.” Apps play sound. The system shows a device. But the audio is routed to a sink you’re not listening to—like shouting into a room you already left.

Identify the active sink + why it flips after updates

Desktop environments can change the default sink after updates, device re-detection, or even after a saved-state restore. If your output device list includes HDMI, “Monitor,” or Dummy Output, the system might “prefer” the wrong one.

If you like CLI visibility, these are common tools (availability can vary by desktop):

# PipeWire-friendly control tool (common on PipeWire systems)
wpctl status

# PulseAudio-compatible tool (often available even with PipeWire)
pactl info
pactl list short sinks

Set a default output that survives reboots

Once you identify the correct sink, set it as default (method depends on your stack). In many cases, choosing the correct output in the desktop sound settings is enough. If it keeps flipping back, that’s a clue: a policy or config is reasserting priority. That’s where WirePlumber rules or device priorities come in—but don’t jump there until you’ve confirmed the basics.

Curiosity gap: Why HDMI/“Dummy Output” steals focus inside a VM

Because the audio system is trying to be helpful: it sees something new (or re-detected) and makes it default. Virtual environments can “reintroduce” devices on boot in ways that trigger that behavior. The fix is to make your desired sink the stable default—and to stop the system from “helping” in the wrong direction.

Driver sanity: confirm the virtual sound card exists (without guesswork)

If you’ve tried controller swaps and service restarts and you still see “no devices,” it’s time to confirm something simple: does Kali even see a sound card? This is not “deep troubleshooting.” This is refusing to argue with reality.

What “good” detection looks like (card listed, sink listed, service running)

Look for evidence in three places: hardware listing, service state, and sinks.

# ALSA-level detection
aplay -l

# Kernel messages (last boot)
dmesg | grep -i -E "snd|hda|ac97|audio" | tail -n 50

# PipeWire/Pulse sinks (depending on what's available)
wpctl status
pactl list short sinks

Interpretation tips (keep it practical):

• If aplay -l shows nothing, the guest isn’t seeing the emulated device (controller/VirtualBox layer is suspect).
• If services are inactive or failing, the Kali audio stack is suspect (restart/reset path).
• If sinks exist but no sound, routing/mute/app-level issues are suspect.

If the device exists but stays silent: the most likely next step

If Kali detects the sound device but output is silent, return to sink routing and confirm the correct sink is selected. If the correct sink is selected, test with a second app. (Browsers can have their own drama. Don’t let one app convict the whole system.)

Open loop: The card shows up, but apps still show no output device—why?

That gap usually means user-space services aren’t exposing sinks cleanly to the session (PipeWire/WirePlumber policy, user service start order, or persistent config). It’s annoying, but it’s also specific. Once you know which layer is failing, you can target it instead of “trying everything.”

Update aftermath: what changed on the day audio died

This section is for people who want the fix and the reason it happened—because you don’t want to repeat the same pain next month. “After update” can mean three different updates: Kali packages, VirtualBox version, or your host OS. If you’re building a long-term lab, it also helps to have a stable baseline for your virtualization stack—VirtualBox vs VMware vs Proxmox tradeoffs can change what “most stable” means for you.

If VirtualBox updated too: why your controller/driver assumptions reset

VirtualBox updates can change audio backends or how the host driver is selected. If your VM audio broke right after VirtualBox updated, it’s especially worth testing:

• Switching the audio controller (Intel HD Audio ↔ ICH AC97).
• Switching the host audio driver/backend (where available).
• Doing a clean VM power-off boot (no saved state).

If only Kali updated: PipeWire/WirePlumber changes that show up as “no sound”

Kali package updates can change service behavior, default policies, and compatibility layers. When it manifests as “no sound,” it’s often not missing packages—it’s services not coming up cleanly, or user config overriding new defaults. If you’re in the middle of leveling up your overall VM workflow, tightening your baseline setup (shell + tooling + habits) matters more than people admit—a clean Zsh setup for pentesters is one of those small “daily friction reducers” that pays off during troubleshooting weeks.

If host OS updated: the hidden link between host audio backend and the VM

Host updates can change device enumeration (especially with Bluetooth devices or HDMI outputs). VirtualBox rides on top of that. If your host suddenly prefers a different output device, your VM can follow it into silence.

Personal note: I keep a tiny “what changed” habit: one line in a note app—“Updated Kali / updated VirtualBox / updated host.” It’s not glamorous. It also makes future you feel like a wizard.

Common mistakes: the detours that waste 30 minutes (or break more)

This is the section you read when you’re tired and tempted to do something dramatic. Consider it a gentle intervention.

Mistake: reinstalling Kali first (almost never necessary)

Reinstalling feels decisive. It’s also often unnecessary. If the root cause is controller mismatch or stuck services, a reinstall buys you a fresh state temporarily—and then the same behavior returns after the next update.

Mistake: changing 5 settings at once (you lose the root cause)

If you switch the controller, host audio driver, and also start swapping audio stacks inside Kali, you’ll eventually stumble into a working setup… and have no idea why. That’s not a fix. That’s a coincidence you can’t reproduce under pressure.

Mistake: switching audio stacks blindly (PipeWire ↔ PulseAudio roulette)

Yes, you can sometimes force PulseAudio back into place. But if PipeWire is the intended stack for your setup, randomly downgrading can create new conflicts. Restart first. Verify. Then decide if you actually need a bigger change.

Who this is for / not for (so you don’t follow the wrong playbook)

For: Kali VM worked before; died after update; host audio still fine

This guide is built for the most common situation: you didn’t change your whole world, you ran updates, and now your VM is silent. You want a safe, reversible flow that respects your time. If you’re building a bigger learning loop around vulnerable machines, keeping your environment stable matters—start with a consistent VM workflow and fold it into a safe hacking lab at home so “audio died” doesn’t derail your whole evening.

Not for: Bare-metal Kali audio issues (different root causes)

If Kali is installed directly on hardware (no VM), your root causes shift: firmware, real drivers, power states, BIOS quirks, and hardware detection. Don’t punish yourself by using a VM guide for bare metal.

Not for: USB audio passthrough + latency/driver conflicts (separate troubleshooting)

If you pass a USB headset directly into the VM, you’re debugging device ownership and USB profiles. It can work great—but it’s not the same problem as emulated audio. If you’re not sure which you’re using, disable USB passthrough for one test and see if emulated audio works.

---

FAQ

Why did Kali lose sound right after apt upgrade in VirtualBox?

Because the update can change user services, policies, or compatibility layers (PipeWire/WirePlumber/Pulse interfaces) that affect device detection and routing. The VM hardware emulation didn’t necessarily change—your guest audio stack behavior did.

Should I use Intel HD Audio or ICH AC97 for Kali in VirtualBox?

Start with what historically worked for your VM. If sound broke after updates or you see “Dummy Output,” try ICH AC97 as a stability test. Intel HD Audio is often fine, but AC97 is frequently more predictable in Linux guests.

Where do I change the audio controller in VirtualBox?

Power off the VM, then open the VM’s Settings → Audio and select the Audio Controller (Intel HD Audio / ICH AC97 / SoundBlaster 16). Boot and test after changing only that one option.

How do I restart PipeWire and WirePlumber without rebooting?

Use user-session systemd restarts: systemctl --user restart pipewire and systemctl --user restart wireplumber. Then confirm sinks exist in sound settings or via wpctl status.

Why does Kali show “Dummy Output” in a VirtualBox VM?

It usually means the session doesn’t see a usable sink. That can happen if the emulated device isn’t detected (controller mismatch), the audio services didn’t start cleanly, or routing defaulted to a non-functional sink. Controller swap + service restart is the fastest proof path.

Is PulseAudio still used on Kali, or is it PipeWire now?

Many modern Linux desktops use PipeWire for audio while still supporting PulseAudio-compatible interfaces so apps continue to work. Practically: you can often use Pulse-style tools (pactl) even when PipeWire is handling the backend.

Does Guest Additions affect sound (or just display/mouse integration)?

Guest Additions mainly improve integration (display resizing, mouse pointer, shared folders). Audio issues are more commonly controller/host-backend/service/routing problems than Guest Additions problems.

Why does audio work in one snapshot but not after an update?

Snapshots can preserve a state where services and routing were healthy. After an update, a service restart or policy change can alter how the sink is chosen. If the fix works once and disappears later, look for persistent config overrides or start-order issues.

What host audio driver should I choose in VirtualBox on Windows?

If your VirtualBox build offers multiple host backends (for example, WASAPI vs DirectSound), test the alternative if audio became unstable after updates. Keep the rest constant while you test. If you’re also comparing platforms for Windows-hosted labs, it helps to understand the real differences between VMware Player vs Workstation vs Fusion so you don’t misdiagnose a “VirtualBox-only issue” that’s actually host-backend behavior.

If nothing works, what’s the safest “last change” to test?

Do one final controlled boot test: switch controller to ICH AC97, disable saved state (full power off), restart PipeWire/WirePlumber after boot, then re-check sinks. If the guest still shows no audio devices at ALSA level, the problem is likely in the VirtualBox layer rather than your desktop routing.

---

Next step: one controlled test you can do in 5 minutes

If you want the shortest path to a repeatable fix, do this exact sequence. It’s designed to isolate the cause with minimal changes.

Do this: switch controller → restart PipeWire → verify sink (stop when it works)

1. Power off the VM fully (not saved state).
2. In VirtualBox: Settings → Audio → set Audio Controller to ICH AC97 (if you were on Intel HD Audio).
3. 
   Boot Kali. Open a terminal and run:
   

   systemctl --user restart pipewire
   systemctl --user restart wireplumber
   wpctl status
   

   
   
4. Open sound settings and select a real output device (not Dummy Output). Test audio.
5. If it works, stop. Record what changed (controller, restart, sink). That’s your repeatable fix.

When you’re done, keep one small promise to your future self: write down the one thing that fixed it. Next update, you’ll spend 5 minutes—not an entire evening—getting sound back. (And if your bigger goal is staying productive inside labs, pair this with a stable baseline like Kali lab infrastructure mastery so troubleshooting doesn’t keep stealing your practice time.)

Last reviewed: 2025-12-23