For the alBufferData function I've found through experimentation that you can generate "data" based on "format" if you stick to these rules:
- 16 bit buffers are little-endian and signed and 0 is the silent position
- 8 bit buffers are unsigned and 128 is the silent position
- for stereo formats the left channel comes first
Q1: Is this documented anywhere?
( not in http://connect.creativelabs.com/openal/Documentation/oalspecs-annote.pdf or in http://lwjgl.org/javadoc/org/lwjgl/openal/AL10.html )
Q2: Can I depend on these facts remaining true?
e.g. if the little-endian-ness depended on my CPU the answer would be "no".
Byte order depends on the CPU - use ByteOrder.nativeOrder().
And yes - 8 bit data is unsigned with a 128 offset, and 16 bit data is signed.
Stereo is left followed by right - for multi channel audio (more then 2) you need to look it up :)
Thanks! That's great.
In fact, looking at the source code for lwjgl-source-2.7.1/src/java/org/lwjgl/util/WaveData.java I can see that happening:
private static ByteBuffer convertAudioBytes(byte[] audio_bytes, boolean two_bytes_data) {
ByteBuffer dest = ByteBuffer.allocateDirect(audio_bytes.length);
dest.order(ByteOrder.nativeOrder());
ByteBuffer src = ByteBuffer.wrap(audio_bytes);
src.order(ByteOrder.LITTLE_ENDIAN);
if (two_bytes_data) {
ShortBuffer dest_short = dest.asShortBuffer();
ShortBuffer src_short = src.asShortBuffer();
while (src_short.hasRemaining())
dest_short.put(src_short.get());
} else {
while (src.hasRemaining())
dest.put(src.get());
}
dest.rewind();
return dest;
}
Is this documented anywhere except by the source?
(and here now :) )