Fix audio crackling issue.

[bonelag]

Fixes the issue of distorted audio transmission across most devices while maintaining low latency.

[Copilot]

Pull request overview

This PR targets reduced audio distortion/crackling during streaming playback on Android by adjusting buffering behavior in the audio renderer while aiming to preserve low latency.

Changes:

• Modifies the AudioTrack buffer sizing selection logic in setup().
• Increases the maximum allowed queued (pending) audio duration threshold before writes are skipped.

Comments suppressed due to low confidence (2)

app/src/main/java/com/limelight/binding/audio/AndroidAudioRenderer.java:136

• case 0/2 in the buffer-size switch no longer assigns bufferSize or breaks, so it falls through and always selects the “larger buffer size” path. This makes the “small buffer” attempts unreachable and changes behavior for i=0/2 (and leaves a whitespace-only line). If the intent is to keep the small-buffer option, restore the assignment+break; if the intent is to remove small buffers to prevent crackling, simplify the switch/loop and update the preceding comment that claims we try small vs large buffers.

            switch (i) {
                case 0:
                case 2:
                   

                case 1:
                case 3:
                    // Try the larger buffer size
                    bufferSize = Math.max(AudioTrack.getMinBufferSize(sampleRate,

app/src/main/java/com/limelight/binding/audio/AndroidAudioRenderer.java:194

• The comment says we only queue up to 40 ms and that this bounds latency at 40 ms, but the code now allows getPendingAudioDuration() < 100. Update the comment(s) (and any intended latency bound) to match the new threshold, or revert the threshold if 40 ms is still the desired limit.

    public void playDecodedAudio(short[] audioData) {
        // Only queue up to 40 ms of pending audio data in addition to what AudioTrack is buffering for us.
        if (MoonBridge.getPendingAudioDuration() < 100) {
            // This will block until the write is completed. That can cause a backlog
            // of pending audio data, so we do the above check to be able to bound
            // latency at 40 ms in that situation.
            track.write(audioData, 0, audioData.length);

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ClassicOldSong]

100ms buffer is way too long.

[deepinbytes]

@ClassicOldSong in my old ass processor i set this at 120 and it worked

[pschaub]

I think it would be ideal if the value could be configured rather than being hard-coded into the code.

[bonelag]

I think it would be ideal if the value could be configured rather than being hard-coded into the code.

i will update 😁