Recovering Haiku Audio When media_server Stops Responding
Recover Haiku media services safely while separating one-client failures, mixer routing, add-ons, drivers, server state, and repeatable bugs.
When audio stops, do not assume media_server is hung merely because restarting media services restores sound. One application can hold a broken node, the mixer can mute a stream, a media add-on can fail, or a driver can stop producing completions. Preserve scope and logs before resetting the graph.
Establish whether the failure is system-wide
Play a known local file in a second native application. Open Preferences → Media and inspect the selected audio interface/output, master control, application stream, and hardware-output levels. Record whether meters move, playback time advances, and the device remains listed.
If only one application is silent, close/reopen it and inspect its format, stream mute, and package version. A global service restart is not the first fix. If all applications are silent or Media preferences cannot enumerate nodes, proceed at Media Kit scope.
Save relevant /var/log/syslog lines for media_server, media_addon_server, the mixer, and audio driver. Note the exact action before failure: application launch, output change, USB removal, sleep, format switch, or update.
Use the supported restart action once
Close media clients that can be closed without losing work. In Preferences → Media choose Restart media services, which the official user guide recommends when audio/video state derails. Wait for nodes to repopulate, reselect the intended output, then relaunch and test the local file.
Do not kill guessed team IDs in arbitrary order. Applications may retain stale node handles and add-on hosting depends on coordinated services. If the preference action is unavailable because the desktop is unstable, save evidence and perform a normal reboot rather than repeatedly forcing teams.
If audio returns, record the restart as a diagnostic result. It distinguishes persistent hardware absence from recoverable media graph/server state, but the trigger still needs isolation.
Isolate add-ons and drivers
List third-party media add-ons installed under user or non-packaged hierarchies and preserve a copy. Boot with user add-ons disabled or temporarily remove only the suspect add-on from the active search path, restart services, and retest with the default mixer.
If a particular codec/file triggers the hang but ordinary audio works, focus on its media/translator add-on and sample. If any stream hangs only after a USB device disconnects, report the device-removal sequence and driver. If the audio node vanishes before media services start, investigate hardware/driver detection rather than roster routing.
For an update regression, compare the previous package state. Do not mix old media_server, Media Kit libraries, and current add-ons by copying individual files; package compatibility must remain coherent.
Capture the blocked state
If the failure repeats, inspect media_server and media_addon_server threads with Debugger or system tools before restarting. Save stacks, thread states, CPU use, and any debug report. A waiting server may depend on a node/add-on thread; a busy loop produces different evidence.
Record active application, media format, sample rate/channels, selected output, node/add-on name, device ID, Haiku revision/architecture, and reproduction count. If one test file causes the problem, keep a minimal non-private sample or document how to generate it.
Check whether restart leaks settings or only resets selection. A service recovery that silently switches to another output can look successful while the original path remains broken.
Verify the repair
After updating/removing the responsible package or applying a fix, reboot normally and reproduce the original sequence repeatedly. Test stop/start, switching outputs, closing the client, and device removal when relevant. Confirm services remain responsive and syslog has no recurring errors.
File system-level media defects with Haiku and application/add-on defects with their maintainer or HaikuPorts as appropriate. Attach full stacks/logs and state exactly whether the supported restart recovers it. This turns “sound died” into a specific lifecycle or node failure developers can act on.
Related:
Sources: