A jump sound that works in a desktop build can fail on a phone for reasons that have nothing to do with the sound itself. The file might be too large for the install budget. The sound might arrive late enough that the jump feels disconnected. Or the voice pool might be too small to play the jump while everything else in the scene is already using voices. Each of those is a separate constraint, and each has a separate fix.
The sections below treat the jump as a case study in mobile audio budgeting: what the file costs, what the input-to-sound path costs, and what the voice costs. The numbers are starting points drawn from platform documentation and middleware guidance, not universal constants. They are useful because they make the trade-offs visible before the sound is final.
The File Size Budget: A Jump Should Be Measured in Tens of Kilobytes, Not Megabytes
Mobile install size is a real constraint. A Godot Android APK with no assets is already around 20 MB installed, before sounds or sprites are added . A project that allocates 1–5 MB for audio is already working inside a tight budget . A jump sound is a single event that fires hundreds of times; it should not be a significant share of that budget.
Published examples give a sense of the scale. A player jump sound in one game asset is listed at 10 KB as a WMA file, and the compiled XNB versions are 56 KB and 176 KB depending on the format . A free retro SFX pack contains 30 sounds at 814.8 KB total, which averages roughly 27 KB per sound . These are not target numbers, but they show that a jump sound is normally a kilobyte-scale asset, not a megabyte-scale one.
The format decision is the main lever. Wwise’s guidance gives ADPCM a compression ratio of roughly 4:1 at low CPU cost, while Opus offers ratios from 10:1 to 60:1 but at higher CPU cost, and is specifically noted as unsuitable for very short files because of the CPU overhead relative to the tiny payload . For a jump that is 100–150 ms long, ADPCM is often the better fit: the file is already small, and the decoder cost of Opus is not repaid by a meaningful size reduction.
The file size reduction guide covers the encoding and bitrate choices in more detail; the jump-specific rule is that the format should be chosen against the file’s duration, not against a generic “most compressed” preference.
The Latency Budget: Mobile Is Not One Number, and the Jump Is the Worst Case
Input-to-sound latency on mobile is not a single figure. It varies by platform, device, audio path, and whether the phone is using its built-in speaker, wired headphones, or Bluetooth. The jump is the worst case because it is tied directly to an input event and because the player expects the sound at the moment of the press.
On Android, the fast mixer path introduced in Android 4.1 is designed to reduce latency, with a recommended mixer period of 2–3 ms, or 5 ms when scheduling stability requires it . Measured round-trip latency on recent devices is roughly 25–40 ms for an AudioTrack-based pipeline: a Pixel 8 with Tensor G3 measured 32 ms, a Galaxy S24 with Snapdragon 8 Gen 3 measured 28 ms, and a Pixel 7a with Tensor G2 measured 41 ms . Those are achievable numbers, not guarantees. Middleware documentation notes that some Android devices exhibit up to 150 ms of latency even though the usual figure is below 100 ms, and that Bluetooth headsets can push latency to 170 ms .
On iOS, AVAudioEngine in low-latency mode with a 256-sample buffer at 48 kHz typically delivers 10–12 ms round-trip latency . A measured touch-to-sound latency on an iPhone SE 3rd generation was approximately 37 ms . The iOS numbers are generally more consistent than Android’s, but they are still not zero, and they can rise with Bluetooth or with a larger buffer.
The practical implication for a jump is that the sound must be scheduled as close to the input event as possible, and the engine’s buffer size must be set with latency in mind. In Unity, the mobile DSP buffer size is set from Audio Settings → Mobile DSP Buffer Size; smaller values reduce latency but can cause instability on some devices, and larger values are more stable but later . The default “Best Performance” setting is a stability-first choice, not a latency-first one.
In Godot, the situation is more constrained: the
audio/output_latency project setting is
ignored on Android, so the latency is
determined by the platform and the export configuration rather
than by that setting . A Godot
Android export with a measured latency of roughly
100 ms and a dropout rate of
5–10% is documented in one optimization
note , which is far above
the 30–40 ms range a jump would ideally sit in. That does not
mean a Godot mobile jump cannot work; it means the latency
budget has to be measured on the target device, not assumed
from the project settings.
The mobile file size and performance guide covers the broader performance side; the jump-specific point is that latency is an input-path property, and the sound design cannot fix a late trigger.
The Voice Budget: A Jump That Plays on Every Frame Will Exhaust a Small Pool
Mobile voice limits are tighter than desktop limits, and the jump is one of the most frequent events in a platformer. A jump sound that is not voice-limited can consume the pool by itself if the player is moving quickly and the input system is retriggering the sound more often than intended.
Middleware guidance gives concrete ranges. Wwise recommends fewer than 50 total channels on low-end Android and iOS devices that are around five years old, and fewer than 100 total channels on recent Android and iOS devices . Another set of guidance puts the physical voice target at under 80 channels for Wii U, Switch, and high-end Android/iOS, and under 40 channels for low-end mobile and older PC . A forum post about Cocos Creator notes that Android can play at most 32 simultaneous instances of audio, with iOS also having a limit .
Those are total-scene budgets, not per-sound budgets. A jump that is allowed to stack without a limit can contribute a disproportionate share. The standard fix is a playback limit on the jump sound: a cap of 2–3 simultaneous instances is usually enough to cover rapid jumps without allowing an unbounded stack. Wwise’s playback limit system supports per-object, per-hierarchy, and global limits, and it treats exceeding the limit as a reason to kill the oldest or lowest-priority instance rather than let the pool overflow.
The sound prioritization and voice limiting guide covers the full hierarchy; the jump-specific rule is that a jump should have a hard cap, not a soft expectation, because it is one of the few sounds that can fire on almost every frame of movement.
A Mobile Jump Patch That Fits All Three Budgets
The table below gives a starting configuration for a mobile platformer jump. The values are chosen to stay inside the file-size, latency, and voice budgets described above, not to match a desktop reference.
| Constraint | Mobile target | Why |
|---|---|---|
| File size | Tens of KB per jump; ADPCM if the file is under ~200 ms | A jump should not consume a meaningful share of a 1–5 MB audio budget; Opus’s CPU cost is not repaid on very short files |
| Latency | Measure on target; aim for the 30–40 ms range where achievable | Recent Android devices reach 28–41 ms; iOS low-latency mode reaches 10–12 ms, but measured touch-to-sound can be higher |
| Voice cap | 2–3 simultaneous jump instances | Low-end mobile total budgets are under 50 channels; an uncapped jump can dominate the pool |
| Sample rate | 48 kHz for consistency with platform mixers; 44.1 kHz only if the engine resamples cleanly | A mismatch between the asset rate and the device output rate adds resampling latency and can change the transient |
| Channel count | Mono | A jump is a player-centred event; stereo doubles the file size and the voice cost without adding information |
The patch is not a guarantee. A device with 150 ms of Android audio latency will make the jump feel late no matter how the file is encoded, and a scene that is already at its voice ceiling will drop the jump before the cap matters. The value of the table is that it separates the three budgets so they can be measured and fixed independently: a file-size problem is solved with a format, a latency problem is solved with the audio path, and a voice problem is solved with a playback limit.
The sample rate and format guide covers the platform-specific encoding decisions; the mobile jump case is a narrow application where all three budgets happen to be tight at the same time.