Android ExoPlayer音频ByteBuffer复制失效问题咨询

Hey there, let's break down why your ByteBuffer cloning attempts aren't working as expected with ExoPlayer's DefaultAudioSink and AudioTrack, and how to fix it.

Why Your Existing Methods Fail #

Let's go through each of your attempts to understand the root causes:

1. Cloning with rewind() calls

   public static ByteBuffer clone(ByteBuffer original) { 
       ByteBuffer clone = ByteBuffer.allocate(original.capacity()); 
       original.rewind();//copy from the beginning 
       clone.put(original); 
       original.rewind(); 
       clone.flip(); 
       return clone; 
   }
   

   The problem here is twofold:

   • ExoPlayer passes ByteBuffers with specific position and limit values that mark the valid audio data range (not necessarily from index 0 to full capacity). Calling rewind() resets the original buffer's position to 0, so you end up copying the entire buffer (including invalid, uninitialized bytes) instead of just the active audio data.
   • Resetting the original buffer's position back to 0 with the second rewind() breaks ExoPlayer's internal buffer management. The framework expects the buffer's state to remain unchanged after writeBuffer completes, so modifying it leads to data being misinterpreted as consumed or empty.

2. Cloning without rewind()
   Removing rewind() means you copy the valid data from the original buffer's current position to limit, but this still moves the original buffer's position to limit during the clone.put(original) call. ExoPlayer will think the buffer's data has been fully consumed, causing unexpected behavior like audio acceleration—this happens because the framework might skip or misalign subsequent buffer data. Additionally, you didn't match the original buffer's byte order (endianness), which is critical for PCM audio data. Default ByteBuffers use big-endian, while ExoPlayer's audio buffers are almost always little-endian, leading to corrupted audio playback.

3. Using ByteBuffer.duplicate()
duplicate() creates a shallow copy that shares the underlying byte array with the original buffer, while maintaining independent position/limit markers. This fails because:

   • ExoPlayer reuses buffers internally. If the original buffer gets overwritten with new audio data after you call duplicate(), your cloned buffer will reference this new data instead of the original.
   • While the state markers are independent, any accidental modification to the cloned buffer's underlying data (if it's a direct buffer) could interfere with the original buffer's lifecycle.

The Correct Cloning Approach #

To safely clone the audio buffer without breaking ExoPlayer's logic or corrupting audio, follow these rules:

• Preserve the original buffer's position and limit state.
• Only copy the valid data range (from position to limit).
• Match the original buffer's byte order.

Here's the working code:

public static ByteBuffer cloneAudioBuffer(ByteBuffer original) {
    // Save the original buffer's state to restore later
    int originalPosition = original.position();
    int originalLimit = original.limit();
    
    try {
        // Calculate the length of valid audio data
        int dataLength = originalLimit - originalPosition;
        // Allocate a new buffer with the same byte order as the original
        ByteBuffer clone = ByteBuffer.allocate(dataLength).order(original.order());
        
        // Use slice() to get a view of the valid data without modifying the original's position
        clone.put(original.slice());
        
        // Prepare the clone for reading (flip sets limit to current position, position to 0)
        clone.flip();
        return clone;
    } finally {
        // Restore the original buffer's state to avoid breaking ExoPlayer's buffer management
        original.position(originalPosition);
        original.limit(originalLimit);
    }
}

Key Details Explained #

• Preserving State: The finally block ensures the original buffer's position and limit are reset to their original values, so ExoPlayer can continue using the buffer as intended.
• Slice() Method: original.slice() creates a new ByteBuffer view pointing only to the valid data range (from position to limit), without altering the original buffer's state.
• Byte Order Matching: order(original.order()) ensures the cloned buffer uses the same endianness as the original, which is essential for correct PCM audio playback.

内容的提问来源于stack exchange，提问作者Ben.