Well, I tried to look a bit into this, but I am not sure if the conclusions are correct… just bare with me…
When you try to load an ogg file, the OpenALSystem has the following code in its createAudioTrack method:
buff = OpenALAudioBuffer.generateBuffer();
try {
AudioLoader.fillBuffer(buff, resource);
}
In the first method (generateBuffer) it allocates a new buffer and in the second one (fillBuffer) it fills the new buffer with data. Now I believe the problem comes from the fact that the original allocated buffer and the data that is inserted, are in different formats slightly. Let me show you.
In jME 1:
The original buffer is created with BufferUtils.createIntBuffer, which allocates a direct buffer. Then later in the AudioLoader.read() method, data is read into a second direct buffer with BufferUtils.createByteBuffer(bytes) and finally buffer.setup(data, channels, bitRate, time, depth); is called which stores the loaded data (from second buffer) into the buffer that was originally created.
In jME 2:
It starts out the same... The original direct buffer is created with BufferUtils.createIntBuffer, which allocates a direct buffer. Then later in the AudioLoader.read() method, data is read into a second buffer BUT in this case the call is BufferUtils.createByteBufferOnHeap(bytes) which creates a
non-direct buffer. Finally in buffer.setup(data, channels, bitRate, time, depth); the loaded data from second buffer is stored in the buffer which was originally created. Now later when AL checks if data is in a direct buffer or not, this check is done against the actual data which is stored inside the buffer.... which is NOT direct.
While this MAY be what is causing the problem, I am not sure how or why the audio system is working atm at all. Maybe I am missing something? For those interested, here is
a bit of info on direct and non-direct buffers from ByteBuffer's javadoc. All in all I'd consider this a bug if no-one corrects me.
For now the workaround might be streaming the audio. All this buffering code is inside a if (!stream) { ... } block, which means that when you call createAudioTrack(String resourceStr, boolean stream)), you can specify the
stream parameter as TRUE, and it should bypass this problematic block. At least thats what caught my eye when looking at this.. I cannot reproduce the problem however . ogg files are loaded fine for me in both streaming and non-streaming modes..
I think someone else should also look into this.
