Music is decoded to PCM samples, processed by tape transport and the effects rack, then sent to Android audio output. The system and headphones may also queue, resample or encode it. One buffer’s size is not the total delay from a finger movement to audible sound.

A PCM frame contains the samples for all channels at one moment; a processing block contains a group of audio frames. Converting frames to time requires the sample rate. Display frame rate or one processing block is not a direct measure of audible latency.

Use wired headphones for live controls. In the developer’s tests, switching to wired headphones resolved the noticeable delay heard with wheel and shake controls over Bluetooth. Actual response still depends on the phone, system and output device.

Foreground output uses the device’s minimum buffer requirement as a floor and a request of about 30 ms to reduce queued audio, so transport controls can affect subsequent sound sooner.

Playback retains at most four read-ahead windows and reuses decoded audio in an on-demand cache capped at 16 MiB. This reduces repeated decoding while bounding memory use. It does not mean the whole track or that much data is queued to the headphones.

The read-ahead window, decoded-audio cache and output-device buffer serve different purposes. Memory capacity cannot be converted directly into actual output latency without distinguishing those stages.

The effects chain updates at audio-block boundaries, with an approximately 20 ms transition between old and new chains to join the sound. That transition can briefly increase processing work, but it does not by itself establish the cause of crackling. If Android accepts only part of a block, the processed remainder is submitted next without running it through the effects again.

Bypass changes the audible result, but the instance still computes to maintain its state. Remove unused instances to reduce processing work.

For crackling, inspect the effects-chain output peaks and reduce excessive effect gain to investigate amplitude clipping. Then remove unneeded effects and compare processing load. Audio can underrun when supply cannot keep up with playback; excessive peaks can clip. The overload light reports peaks, not underruns. These steps narrow the possibilities rather than establish a diagnosis.

In the background, playback submits PCM in batches at normal 1× speed and retains effects processing. An empty rack requests about 200 ms of buffering; a rack with effects requests about 600 ms, limited by the allocated capacity.

A larger background buffer gives system scheduling jitter more room; sustained processing that cannot keep up can still underrun. Returning to the foreground restores smaller buffer settings, but audio already queued still has to be consumed.

Wheel drawing retains only the latest state and at most one pending draw, reducing outdated work. Display updates and audio output are different paths: audible Bluetooth delay does not directly explain dropped display frames.

When the app goes into the background, the screen turns off or the corresponding feature is disabled, the relevant orientation-sensor readings and listeners stop. Dynamic reflections change lighting, not sound; shake simulation affects sound through its own switch.

The published evidence is currently the developer’s qualitative wired-versus-Bluetooth observation. Reproducible numerical measurements of end-to-end latency, processing load or power consumption with full conditions have not been published.

Comparisons need the phone model, system version, output device and connection, sample rate, effects chain and the same test passage. Request sizes and buffer targets cannot replace measurements. Ten rack slots describe chain capacity, not smooth performance for every combination, a fixed latency or a promised power saving.