The Nintendo Switch is the only current console that ships with two completely different output environments in the same box. A player can play the same game docked to a TV with a 5.1 surround system, or in handheld mode with built-in stereo speakers, or with headphones plugged into the 3.5mm jack. The audio has to work in all three environments without a separate mix for each. That is the defining constraint of Switch audio design, and every other decision flows from it.
The hardware is not the limitation that developers assume. The Switch has 4 GB of LPDDR4 shared between the CPU and GPU, and the audio subsystem is capable of 48 kHz 16-bit output through the I2S bus to the Realtek ALC5639 codec. The console outputs 5.1 linear PCM over HDMI when docked, and stereo through the built-in speakers or headphones when undocked. The audio core is not dedicated to audio the way the Xbox 360 had a dedicated audio CPU; it is a shared resource, and that sharing is what creates the specific optimization challenges.
The Steam Deck optimization guide covers the handheld PC category, which shares some of the same constraints but has a fundamentally different operating system and audio stack. The Switch is a closed platform with its own SDK, its own codec preferences, and its own loudness recommendations. This article covers the specifics of designing for that platform.
What is the voice count budget on Switch, and why is it lower than the hardware suggests?
The Switch's audio core runs at 48 kHz and can mix multiple channels of 16-bit audio, but the practical voice count budget for game audio sits around 32 voices for a software-decoded mix and around 150 physical voices when using Wwise with virtual voice management. The difference between those two numbers is the difference between a naive implementation and a managed one.
FMOD's platform documentation recommends 32 voices as the reference configuration for Switch, with a 24 kHz sample rate and stereo output as the baseline assumption. The 24 kHz figure is not a hardware limit; it is a resource tradeoff. Running the audio pipeline at 24 kHz instead of 48 kHz halves the CPU cost of every DSP operation and halves the memory footprint of decoded audio, at the cost of losing content above 12 kHz. For most game sound effects, which have little useful content above 10 kHz, the tradeoff is favorable.
The 32-voice budget is lower than the hardware can theoretically support because the audio core is shared with the rest of the system. When the CPU is under load, the audio core may not get scheduled every frame, and the voices that are supposed to be mixed are delayed or dropped. The voice count budget is a conservative estimate of what can be maintained consistently, not a hard ceiling.
The voice limiting system is essential on Switch for the same reason it is essential on mobile. The budget needs to be set conservatively, and the prioritization needs to drop low-priority sounds before the limit is reached. A game that runs comfortably at 64 voices on desktop should be tested at 32 on Switch, with the priority thresholds adjusted so that the sounds that matter are the ones that survive.
Which audio codec should you use, and why does the hardware decoder limit matter?
The Switch has a small number of hardware audio decoders available. Community reports from Wwise users place the limit at approximately 24 hardware decoders, though the exact number is not publicly documented by Nintendo. When the game exceeds this limit, the middleware falls back to software decoding, which consumes CPU cycles that the game may not have available.
The codec choice that FMOD recommends for Switch is FADPCM as the primary format, with Vorbis as the secondary choice for long streams where FADPCM compression is insufficient. FADPCM is a fixed-point ADPCM variant that is inexpensive to decode and produces a predictable CPU load. Vorbis produces better compression but costs more CPU per decoded stream.
| Codec | CPU cost | Compression | Best for |
|---|---|---|---|
| PCM (uncompressed) | None | 1:1 | Short sounds that play frequently |
| FADPCM | Low | 4:1 | Most sound effects |
| Vorbis | Medium to high | 8:1 to 12:1 | Music, long ambience |
| Opus | High | 10:1 to 16:1 | Large streams, limited by decoder count |
The practical strategy that has worked for other Switch ports is to use Opus for music and other large streams where the compression benefit is greatest, and FADPCM for the sound effects. This keeps the number of simultaneous Opus streams low enough that the hardware decoder limit is not exceeded, while still getting the CPU benefit of FADPCM for the sounds that play most frequently.
The Wwise profiler's "Physical Voices" counter is the diagnostic to watch. A reasonable target on Switch is around 150 physical voices, and the Virtual Voices and Limits system should be configured to keep the count below that. If the profiler shows the physical voice count spiking above 150 during gameplay, the decoding cost is likely the cause of any frame rate drops.
There is one Switch-specific caveat that catches developers off guard. Enabling haptic feedback through Wwise Motion on Switch can cause audio stuttering even when CPU usage remains low and the voice count is within budget. The issue is not a CPU limit; it is a scheduling conflict between the audio core and the vibration subsystem. If a Switch build stutters with haptics enabled but not with haptics disabled, this is the likely cause. The haptic synchronization guide covers the general design of haptic feedback; on Switch, the implementation may need to be throttled or disabled for specific sound categories to avoid the conflict.
What loudness targets should the mix hit for Switch?
The Interactive Entertainment Sound Developers group, a branch of the Game Audio Network Guild, publishes loudness recommendations for console titles. The recommendations apply to Sony, Microsoft, and Nintendo platforms equally, and they are measured according to the ITU-R BS.1770-3 standard.
| Target | Value | Notes |
|---|---|---|
| Average loudness (console) | -23 LUFS | ±2 LU tolerance |
| Average loudness (portable) | -18 LUFS | Higher because of speaker limitations |
| True peak maximum | -1 dBTP | ITU-R BS.1770-3 compliant meter |
| Measurement duration | At least 1 hour | Broad cross-section of gameplay |
The difference between the console target and the portable target is the most important detail for Switch. A game that is mixed to -23 LUFS for the docked TV experience will sound quiet when played through the built-in speakers, because those speakers reproduce very little energy below 100 Hz and have limited output above 10 kHz. The -18 LUFS portable target is 5 dB louder, which compensates for the smaller speakers without clipping the output.
The Switch does not have a built-in loudness normalizer that switches between the two targets automatically. The game has to detect whether it is docked or undocked and apply the corresponding target. The most common approach is a separate master bus gain setting for each mode, adjusted so that the measured loudness lands on the appropriate target. The -1 dBTP peak limit applies in both modes; the true peak measurement should be taken with a BS.1770-3 compliant meter over a long enough session to cover the loudest moments in the game.
The audio mix hierarchy guide covers how to structure the bus tree so that a single gain adjustment on the master bus can shift the entire mix between the two targets without rebuilding the mix.
How does the built-in speaker and headphone output change the mix?
The Switch's built-in speakers are stereo drivers mounted in the handheld enclosure. Their frequency response rolls off below roughly 100 Hz and has limited extension above about 10 kHz. The practical result is that the mix has to be designed for the mid-range, because that is the only range the speakers reproduce with authority.
The first adjustment is a high-pass filter on the master bus, typically at 80 to 100 Hz, that removes the inaudible sub-bass content. This is the same technique described in the mobile optimization guide, applied for the same reason: the content below the speaker's reproduction range is consuming headroom without producing audible output.
The second adjustment is to shift the perceived weight of important sounds into the 150 to 400 Hz range. A weapon impact with its body at 200 Hz will read as impactful on the Switch's speakers; the same impact with its body at 80 Hz will read as thin. The weapon sound layering guide covers how to adjust the frequency balance of a layered sound without changing its character.
The headphone output is a different environment and the mix does not need the same high-pass filter. Headphones reproduce the full frequency range, and a mix that is high-passed at 100 Hz will sound thin and weak through headphones. The solution is to apply the high-pass filter only when the output is the built-in speakers, and to bypass it when headphones are connected or when the console is docked and outputting through HDMI.
The Switch's headphone jack has a known noise issue on some units. Community reports describe audible hiss during quiet moments, particularly during loading screens and low-activity scenes. The hiss is present on both in-ear and over-ear headphones and is not limited to sensitive models. This is a hardware characteristic rather than something the game audio can correct, but it is worth knowing when evaluating a mix on Switch hardware. A sound that seems to have an unusually high noise floor through the headphone jack may be the hardware rather than the audio content.
How do you handle the docked and undocked transition?
The Switch switches between docked and undocked output automatically when the console is placed in or removed from the dock. The audio output destination changes from the HDMI connection to the built-in speakers, and the loudness target changes from the console target to the portable target. The game has to detect this transition and adjust the mix accordingly.
The transition itself is not instantaneous. There is a brief moment when the audio output is being rerouted, and the game may receive a notification from the system that the output has changed. The most common approach is to listen for the system's docking callback and apply the corresponding mix preset. A short fade to silence during the transition prevents a click or pop from being sent to the new output.
The 5.1 surround output through HDMI is a separate consideration. When docked, the Switch can output 5.1 linear PCM through the HDMI connection, and the game can use this for positional audio that is not available in handheld mode. The 3D positional audio guide covers the general approach; on Switch, the 5.1 output is the docked-only path that allows the positional mix to be more detailed than the stereo handheld version.
The practical approach that works for most games is to build the mix in stereo as the primary version, with the surround version derived from it by the middleware's spatialization system. This ensures that the handheld mix is correct, and the docked surround mix is an enhancement rather than a separate production. The engine comparison covers how Unity and Unreal handle the platform-specific audio settings that make this possible.
What does a Switch-specific audio test look like?
The first test is the docked/undocked comparison. Play the same scene docked and undocked and listen for whether the mix translates. The dialogue should be audible in both modes, the important sounds should be distinguishable, and nothing should sound thin or missing when the console is undocked.
The second test is the headphone test. Plug headphones into the 3.5mm jack and play the same scene. The mix should not sound thin or weak, which would indicate that the high-pass filter is being applied incorrectly. The noise floor should be acceptable; if the hiss is audible during quiet moments, it is the hardware and not the mix.
The third test is the voice count test. Use the Wwise profiler or FMOD's profiler to watch the physical voice count during a scene with high audio activity. The count should stay below the budget of approximately 150 physical voices. If the count spikes above that, the decoding cost is likely consuming CPU that the game needs.
The fourth test is the haptics test. If the game uses haptic feedback through the Joy-Con, enable it and play a scene with heavy audio activity. If the audio stutters with haptics enabled but not with them disabled, the scheduling conflict described earlier is the cause. The fix is to reduce the haptic update rate or to disable haptics for specific sound categories.
The fifth test is the loudness measurement. Use a BS.1770-3 compliant meter to measure the game's average loudness over a long session. In docked mode, the target is -23 LUFS ±2; in handheld mode, the target is -18 LUFS ±2. The true peak should not exceed -1 dBTP in either mode. The file size reduction guide covers the metering tools that are appropriate for this measurement.
The Switch is a platform where the audio design decisions are constrained by the hardware in specific, documented ways. The voice count budget is lower than the hardware suggests. The codec choice is limited by the number of hardware decoders. The loudness target changes between docked and undocked. The speakers reproduce the mid-range but not the extremes. Each of these constraints is manageable, and none of them requires compromising the design of the individual sound effects. They determine the mix, the file format, and the runtime configuration, and they are the same constraints that every Switch game faces regardless of genre or budget.
Generate Mid-Range Focused Sound Effects for Switch
Open the SfxMaker generator and create sound effects with energy concentrated in the 150 to 400 Hz range rather than below 100 Hz. The Switch's built-in speakers reproduce the mid-range with much more authority, and a sound designed for that range will translate to the handheld mix without requiring a separate version.
Open SfxMaker Generator →