Tutorials · 15 min read

Optimize audio latency without sacrificing quality

Find the lowest stable buffer for your Android rig, preserve clean audio, and check real playing response with your full performance setup.

Your guide, your screenAndroid · landscape
Showing phone screenshots and instructions

Before you begin

  • A saved copy of your performance preset and ready sound-library files.
  • A wired listening output. A MIDI keyboard is useful for checking your performance response, but you can begin with the onscreen keyboard.
  • Audio settings are available in Free Demo. Its timed sessions and muted keys still apply; use plan-compatible instruments and effects, or Player and above for unrestricted rehearsal sessions.
  • Tune before a service or recording: changing sample rate or output can restart playback.

1. Establish a clean starting point

Use an available onscreen key to confirm the starting sound is clean.Pixel 10a
  • Play a key to audition the current sound.

Start with wired headphones or a compatible USB audio interface, 48 kHz and a 256-frame buffer. If 256 crackles, begin at 512. Once playback is clean, try 128 and compare. Your target is the lowest buffer that stays clean with your complete rig after it warms up.

The current app’s initial buffer preference is 128 frames; selecting 256 is a deliberate stability baseline for this procedure. The Audio menu also offers Auto. Auto can adjust the Android output buffer under load, so inspect the active values rather than assuming that it will stay at one fixed size.

  1. Save the current preset and note the existing output, sample rate and buffer so you can restore them.
  2. Tap Settings, then Audio in the category list, scrolling if needed. Use the back arrow to return to the list.
  3. Confirm the intended device in Output and its Active label. If playback has not started, use Start Patch.
  4. Choose 48 kHz in Sample Rate, allow playback and sounds to restart, then choose 256 frames in Buffer Size.
  5. Play a simple, ready piano sound through the wired output before adding the rest of your rig.

2. Understand the delay you are hearing

Playing response includes the keyboard’s scan, MIDI delivery, the app’s sound generation, audio buffering, output hardware and the monitor/PA path. The duration shown beside Buffer Size describes one processing block. It is not the total time between pressing a key and hearing a speaker.

The app’s reported output latency covers the output path it can report or estimate. It is not a full key-to-ear or round-trip measurement, and some hardware does not report it. Do not add every displayed time together: some fields describe overlapping parts of the same path.

Compare outputs on the actual Android device. Its built-in speaker can have a different path from wired headphones or a USB interface. Bluetooth headphones and speakers add their own device-dependent wireless delay; reducing the app buffer cannot remove that downstream delay. Use wired monitoring as your first comparison.

The playing-response chain extends beyond the app buffer

Key to ear

  1. Keyboard / MIDI
  2. InPraise Keys processing
  3. Output / DAC
  4. Mixer / monitors
  5. What you hear

3. Tune the buffer one step at a time

The Audio page exposes the active output, sample rate and Buffer Size selector.Pixel 10a
  • Choose the audio output device here.
  • Select the audio sample rate here.

A smaller buffer gives the engine less time to finish each block. A larger buffer provides more scheduling margin. Buffer size changes timing, not the sample resolution; increasing it to remove underruns can improve the cleanliness of playback without lowering the recording or output bit depth.

At 48 kHz, one block’s duration is frames ÷ 48,000 × 1,000 milliseconds. The values below explain the menu’s processing-time labels, not a promised end-to-end latency.

One processing block at 48 kHz
BufferOne blockWhen to try it
64 frames1.33 msOnly after 128 is stable. Your output’s hardware burst or USB backend can prevent a corresponding reduction.
128 frames2.67 msA responsive candidate after 256 passes the full-rig test.
256 frames5.33 msThe starting candidate in this guide; compare stability and feel.
512 frames10.67 msTry when 256 crackles, particularly with a demanding preset or USB output.
1,024 frames21.33 msMore processing margin on the Android path, with a longer block. Useful diagnostically; evaluate playing feel.
  1. At 256 frames, play repeated notes, dense chords and sustained passages with the complete preset.
  2. If you hear clicks or gaps, try 512 and repeat the same passage. If the problem persists, check output, power and DSP load before continuing.
  3. If 256 is stable, try 128. Change only one setting at a time and repeat the same test.
  4. If 128 is stable and the actual output supports a useful reduction, compare 64. If it crackles or sounds no more responsive, return to the last stable choice.
  5. Keep some margin for the performance: if a setting barely survives the test, use the next stable step and rehearse again.

4. Preserve sound quality and level headroom

Balance the complete mix and check the output while playing your loudest passage.Pixel 10a
  • Tap the instrument name to open its picker.
  • Drag the channel fader to balance its level.

Keep 48 kHz as the first sample-rate choice. It is the app’s low-latency default and a common Android hardware rate. The other app option is 44.1 kHz; use it when your actual device/workflow requires it, then verify the negotiated output and repeat the buffer test. A higher advertised interface rate does not automatically make this app more responsive.

Balance instruments, buses and the final output so the loudest layered passage stays clean. If notes distort even with a generous buffer, lower the levels and compare with effects bypassed. Buffer underruns and clipping are different problems; raising the buffer does not repair an overloaded mix.

Use EQ and reverb for the sound you need, then reduce redundant processing before sacrificing the core instrument tone. Where instruments already share an appropriate category bus, consider one bus effect rather than repeated channel copies. Recheck the balance because changing where an effect runs changes how it shapes the mix.

If you record the rehearsal, keep the original WAV for your quality reference. The recording format does not set the live audio buffer. Listen to the live output as well: an internal recording does not independently verify everything downstream in the USB device, mixer and PA.

5. Leave room for the busiest passage

Tune preloading and idle-channel processing for the actual setlist, rather than loading every available sound.Pixel 10a
  • Turn off animations to reduce movement in the interface.

Tap Settings, then Performance in the category list, scrolling if needed. Use the back arrow to return to the list.

Enable Conserve idle channels to bypass inserts on muted or powered-off channels. A layer at volume zero can still be live for expression, so it is not the same as switching an unused channel off. Reduce unnecessary active layers or long effect tails if the busiest passage still overloads the rig.

Use Earlier presets and Later presets to warm the nearby sounds you actually need. Both at zero use the least memory. Preloading can make transitions more dependable, but loading more sounds also consumes resources. If Preload while playing coincides with glitches, compare loading beforehand with that option off and test the transitions again.

In Audio, try Performance Mode if your device supports it. It uses the performance core group and supports playback with the screen off or another app open, with a battery/heat cost. If the app reports no separate performance core group, leave the setting off and continue testing the buffer and preset load. Give the device ventilation, especially while charging.

Keep Mix With Other Apps off when you do not need concurrent playback, and stop unnecessary background audio or download activity. The setting governs audio sharing/focus; it is not a guaranteed latency switch. A directly driven USB interface remains exclusive to the app. Test with the same companion apps you will actually use on stage.

6. Read the active statistics

Show stats for nerds reveals the values reported by the current output route.Pixel 10a
  • Show stats for nerds reveals live audio path details.
  • Reported output latency includes the device audio path.

Tap Settings, then Audio in the category list, scrolling if needed. Use the back arrow to return to the list.

Scroll to Status and enable Show stats for nerds. Inspect the active route while playing the same demanding passage. Note the underrun count before and after a test; an old cumulative count is less useful than whether it rises during your playing.

Active sample rate / Device rate
Compare the running stream with the hardware rate when it is reported. A selected preference is not the complete description of the negotiated route.
Processing / callback frames
The block currently processed. It can differ from the requested setting or hardware burst.
Device queue / Burst
Frames queued for output and the device’s scheduling unit. A small menu value cannot override every hardware limitation.
Underruns
A rising count means the output did not receive audio in time. Increase the buffer or reduce the load, then repeat. Not reported does not mean zero.
DSP / peak callback
Use these alongside listening. An average DSP figure can hide a costly peak; compare the same passage and keep processing margin.
Reported output latency
A route-specific report or estimate, not a physical measurement of complete keyboard-to-speaker response.
Direct hardware / system mixer path
The route the device actually grants. There is no settings switch that guarantees a direct hardware path on every output.

7. Separate app response from the monitoring path

Capture verifies whether the connected MIDI source is delivering notes to the app.Pixel 10a
  • Use Capture to start or pause the MIDI event log.

If the app sounds clean but playing still feels late, compare the same instrument through local wired headphones and the normal stage monitoring path. If only the stage path feels late, ask the sound engineer to inspect mixer processing, monitor routing and any wireless or delayed speaker path.

Compare the onscreen keyboard with the MIDI keyboard through the same output. If only the external controller feels slower, inspect its connection and MIDI delivery. A slow attack envelope or intentionally delayed effect can also make a pad feel late even when a dry piano is responsive.

  1. Use one dry piano with a clear attack and play short notes through wired headphones.
  2. Play the same sound from the MIDI keyboard. Check Midi Settings > Capture if messages are missing or inconsistent.
  3. Listen through the PA/monitor path without changing the preset or buffer. Identify where the feel changes.
  4. Restore the intended layers/effects and compare again. Change the offending envelope, effect or downstream route only after isolating it.

8. Verify the working settings before a service

Use the same named setlist for the repeatable rehearsal and record it with the settings.Pixel 10a
  • Tap + Setlist to create a list.
  • Choose a preset in the selected setlist; its row actions are on the right.

Run the full setlist after the rig has warmed up, with the exact power supply, hub, output, monitoring and companion apps you intend to use. Include your busiest chords, sustain releases, state changes, preset transitions, Worship Pads and recording if those are part of the service.

A short clean test is a starting point. Repeat for a full rehearsal, checking for new underruns, dropouts, changing playing feel and thermal slowdowns. If a buffer only works when the device is cold or the preset is simple, step back to the last setting that remains stable under your real workload.

  1. Choose the lowest buffer that stayed clean throughout the representative test, with useful playing feel and processing margin.
  2. Reopen the app with the complete rig attached and verify the active output, driver, rate and buffer again.
  3. Write down the Android device/OS, app version, interface, USB driver, sample rate, requested buffer and reported active frames, plus the preset/setlist used.
  4. Keep that working configuration as your reference. Change settings and retest during rehearsal rather than in the middle of a service.

Expected result

What you should have now

Your complete rig has a documented wired output and buffer that stays clean during a representative rehearsal. You understand which figures describe processing blocks, which describe the reported output path, and which delays must be checked outside the app.

Common problems

Clicks or gaps appear as you lower the buffer
Return to the last stable step, test 256 or 512, and compare DSP peaks and rising underruns. Also check USB power and data connections.
64 or 128 does not produce the expected improvement
Inspect active frames, hardware burst and device queue. Direct USB maps 64 to 128, and the complete output path may dominate the delay.
Latency grows while using Auto
Auto can adapt the Android output buffer under load. Inspect the current values and compare a stable fixed size after resolving the workload that caused underruns.
Only the Bluetooth or PA path feels late
Compare local wired headphones first. Work on the wireless/monitor route with the sound engineer; a smaller app buffer cannot remove all downstream delay.
Playback distorts without increasing underruns
Check channel, bus and output levels. Lower the mix and compare with effects bypassed; clipping is different from a late audio callback.
A missing-sound warning appears
Use Download Manager to prepare the required bank or effect asset. Buffer changes do not download a missing sound.
Performance Mode cannot be enabled
Some devices expose no separate performance core group. Follow the app’s message and use buffer, workload and power/temperature checks instead.
The rig works cold but crackles later
Rehearse while charging with the complete rig, provide ventilation, reduce unnecessary load and use a larger stable buffer. Include the affected preset and hardware details when contacting support.