alBufferData() and the meanings of AL_FORMAT_STEREO16 AL_FORMAT_STEREO8 etc

[ouattwtym]

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".

[Matthias]

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

[ouattwtym]

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   )