Java Queue, Arrays, and JNI

Question

I think this is a general Java question, but it does involve some Android stuff.

So here's the deal: I've got a JNI wrapped version of MPG123 for Android, and I can pull PCM data from an MP3 file on the SDCard. I'd like to pull a chunk this data, do an analysis on it using another class I wrote, then push it into a queue. Ideally, I'd like the audio to play back with a four second delay. I achieved it with no delay using this code:

public void run() 
{
  // The actual thread where the PCM data gets processed and analyzed
 short[] pcm = new short[ 4096 ];
 short[] zero = new short[ 4096 ];
 Queue<short[]> buffer = new LinkedList<short[]>();

 // Fill the zero buffer
 for( int i = 0; i < 4096; i++ )
  zero[i] = 0;

 // Push back 4 seconds of silence - Note this commented section
 //for( int i = 0; i < 43; i++ )
 // buffer.add( zero );

 // Analyze the whole file 
 while( !isInterrupted() )
 {
  // Grab and analyze data, add events
  int ret = audio.GetPCM( pcm );
  //Log.d( "AudioThread", "GetPCM returns: " + ret );
  if( ret != MPG123.MPG123_DONE )
  {
   // Process the PCM data
   if( bd.Process( pcm ) != BeatDetection.AUDALYSIS_OK )
    Log.v( "AudioThread", "Beat Detection Error!" );

   // Add the data to the PCM buffer
   buffer.add( pcm );
  }

  // Play the audio
  short[] data = buffer.poll();
  if( data != null ) // If we have data left in the buffer
   at.write( data, 0, 4096 ); // Write it to the audio track
  else
   break; // Otherwise we need to exit the loop

  Log.d( "AudioThread", "BufferSize= " + buffer.size() );
 }

 // Debug message
 Log.d( "AudioThread", "Exiting Thread." );

 // Clean stuff up
 bd.Cleanup();
 audio.Cleanup();
 at.stop();
 at.release(); 
 }

That said, when I try to introduce a delay into my queue by adding "4 seconds" worth of 0's into the queue (Note the commented block), my music plays right away, but starts 4 seconds into the song and plays in realtime until the queue starts to empty where it plays the same chunk over and over until breaking out of the loop. It almost seems as if the queue is acting like a "First In Last Out" queue rather than a "First In First Out" queue.

Perhaps I'm not using a Java Queue correctly? Maybe this is some odd bug with the android AudioTrack?

Thanks!

-Griff

EDIT - I solved the problem. It appears to be a problem with my JNI implementation of GetPCM. It appears that when I copied data into PCM from the JNI level, it set the same data for every instance of PCM pushed back into the queue, setting every PCM entry in the queue to the same frame of PCM data. I solved the problem by changing:

buffer.add( pcm );

to

buffer.add( pcm.clone() );

New Question: Is this normal Java behavior? Did I implement the JNI function incorrectly?

JNIEXPORT jint JNICALL Java_com_motalenbubble_projectlucid_MPG123_GetPCM(
    JNIEnv* env,
    jobject obj,
    jshortArray data ) // jshortarray already has a size attribute
{
    // Call mpg123_read
    jint  err  = MPG123_OK, length;
    jshort *pcm;
    jsize len = (*env)->GetArrayLength( env, data );

    pcm = (*env)->GetShortArrayElements( env, data, NULL );
    err = mpg123_read( mh, (unsigned char*)pcm, len * sizeof( short ), &length ); // Read length is in bytes - we need in shorts. 
    (*env)->ReleaseShortArrayElements( env, data, pcm, 0 );
    // Annoying logging
    //dprintf(0, "read(%d): %s\n", length, err == MPG123_ERR ? mpg123_strerror(mh) : mpg123_plain_strerror(err)); 
    return err;
}

Answer 1

It looks like the role of your JNI function is:

Pass it an initialized buffer (i.e. a java short array object), and it will be filled with the next chunk of samples from the mp3 decoder.

For the purpose of doing this task, it appears to be implemented correctly. The function never instantiates a java short array object, and I don't think it should be expected to.

I'll give a description of the problem, although it seems you already understood what was happening.

In your run() method, for the pcm variable you instantiate a short array once. Every time you call audio.GetPCM( pcm ), you're giving it the same array object. And then when you call buffer.add( pcm ), it always enqueues a reference to the same array. So, if you call GetPCM, and then call GetPCM again before you have written the frame to the audio device, GetPCM will disastrously overwrite the array.

You solved the problem with buffer.add( pcm.clone() ) because this always allocates a new array, and adds a reference to that new array to the queue. GetPCM still overwrites the same array (pcm) every time, but it's not a problem because the queue contains references to unrelated arrays, which were created as copies of previous contents of the pcm array.

The problem isn't really related to Android or JNI; GetPCM could equally be implemented in pure Java and the same issue would arise.

---

Using pcm.clone() is a safe solution, but it may not be the most efficient because it requires a new array to be instantiated for every frame.

If you don't need to decode the mp3 data in advance, then you should be able to design a mechanism which prevents GetPCM from being called until the queue is empty, and you can get by with one or two pre-allocated buffers.

On the other hand, if you absolutely need to decode the mp3 data four seconds in advance, then you will inevitably need a lot of buffer space. But generally, performance is better if memory is allocated once at the beginning, and reused, and not repeatedly dynamically allocated.