Skip to content

Fix audio crackling issue.#520

Open
bonelag wants to merge 1 commit intoClassicOldSong:moonlight-noirfrom
bonelag:moonlight-noir
Open

Fix audio crackling issue.#520
bonelag wants to merge 1 commit intoClassicOldSong:moonlight-noirfrom
bonelag:moonlight-noir

Conversation

@bonelag
Copy link
Copy Markdown

@bonelag bonelag commented Feb 21, 2026

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

Copilot AI review requested due to automatic review settings February 21, 2026 05:01
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Copy Markdown
Owner

100ms buffer is way too long.

@deepinbytes
Copy link
Copy Markdown

deepinbytes commented Mar 21, 2026

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants