Here's what seems to work. I load the data in an ajax call with the response type "arraybuffer". Otherwise, the response ends up being a string and it is a mess to work with. Then I convert to a 16-bit array. Then I convert that to a Float32 array in the way that works with the WAV encoding. I also needed to throw away the WAV's header, and some metadata at the end of it.

// These are ready to be copied into an AudioBufferSourceNode's channel data.
var theWavDataInFloat32;

function floatTo16Bit(inputArray, startIndex){
    var output = new Uint16Array(inputArray.length-startIndex);
    for (var i = 0; i < inputArray.length; i++){
        var s = Math.max(-1, Math.min(1, inputArray[i]));
        output[i] = s < 0 ? s * 0x8000 : s * 0x7FFF;
    }
    return output;
}

// This is passed in an unsigned 16-bit integer array. It is converted to a 32-bit float array.
// The first startIndex items are skipped, and only 'length' number of items is converted.
function int16ToFloat32(inputArray, startIndex, length) {
    var output = new Float32Array(inputArray.length-startIndex);
    for (var i = startIndex; i < length; i++) {
        var int = inputArray[i];
        // If the high bit is on, then it is a negative number, and actually counts backwards.
        var float = (int >= 0x8000) ? -(0x10000 - int) / 0x8000 : int / 0x7FFF;
        output[i] = float;
    }
    return output;
}

// TEST
var data = [ 65424, 18, 0, 32700, 33000, 1000, 50000 ];
var testDataInt = new Uint16Array(data);
var testDataFloat = int16ToFloat32(testDataInt, 0, data.length);
var testDataInt2 = floatTo16Bit(testDataFloat, 0);
// At this point testDataInt2 should be pretty close to the original data array (there is a little rounding.)

var xhr = new XMLHttpRequest();
xhr.open('GET', '/my-sound.wav', true);
xhr.responseType = 'arraybuffer';

xhr.onload = function(e) {
    if (this.status === 200) {
        // This retrieves the entire wav file. We're only interested in the data portion.
        // At the beginning is 44 bytes (22 words) of header, and at the end is some metadata about the file.
        // The actual data length is held in bytes 40 - 44.
        var data = new Uint16Array(this.response);
        var length = (data[20] + data[21] * 0x10000) / 2; // The length is in bytes, but the array is 16 bits, so divide by 2.
        theWavDataInFloat32 = int16ToFloat32(data, 22, length);
    }
};

xhr.send();

I emailed the developer of glMatrix and my answer below includes his comments (points 2 & 3):

1. Creating a new object is generally quicker with Array than Float32Array. The gain is significant for small arrays, but is less (environment dependent) with larger arrays.

2. Accessing data from a TypedArray (eg. Float32Array) is often faster than from a normal array, which means that most array operations (aside from creating a new object) are faster with TypedArrays.

3. As also stated by @emidander, glMatrix was developed primarily for WebGL, which requires that vectors and matrices be passed as Float32Array. So, for a WebGL application, the potentially costly conversion from Array to Float32Array would need to be included in any performance measurement.

So, not surprisingly, the best choice is application dependent:

• If arrays are generally small, and/or number of operations on them is low so that the constructor time is a significant proportion of the array's lifespan, use Array.

• If code readability is as important as performance, then use Array (i.e. use [], instead of a constructor).

• If arrays are very large and/or are used for many operations, then use a TypedArray.

• For WebGL applications (or other applications that would otherwise require a type conversion), use Float32Array (or other TypedArray).

DataView doesn't "convert UInt32, Int32 and Float32 to bytes", it converts JavaScript Numbers to bytes in UInt32, Int32, and Float32 formats. How the bytes are stored in a DataView and the underlying ArrayBuffer is an implementation detail.

(A lot has changed since 2011 when this answer was posted - see updates below)

2019-June Update

BigInt has been out in V8 (Node.js and Chromium-based browsers) since May 2018. It should land in Firefox 68 - see the SpiderMonkey ticket. Also implemented in WebKit.

BigDecimal hasn't been implemented by any engine yet. Look at alternative library.

2015 Update

It's been over 4 years since I wrote this answer and the situation is much more complicated now.

Now we have:

• typed arrays
• asm.js
• emscripten

Soon we'll have:

• WebAssembly with the spec developed on GitHub

It means that the number of numeric types available in JavaScript will grow from just one:

• 64-bit floating point (the IEEE 754 double precision floating-point number - see: ECMA-262 Edition 5.1, Section 8.5 and ECMA-262 Edition 6.0, Section 6.1.6)

to at least the following in WebAssembly:

• 8-bit integer (signed and unsigned)
• 16-bit integer (signed and unsigned)
• 32-bit integer (signed and unsigned)
• 64-bit integer (signed and unsigned)
• 32-bit floating point
• 64-bit floating point

(Technically the internal representations of all integer types are unsigned at the lowest level but different operators can treat them as signed or unsigned, like e.g. int32.sdiv vs. int32.udiv etc.)

Those are available in typed arrays:

• 8-bit two's complement signed integer
• 8-bit unsigned integer
• 8-bit unsigned integer (clamped)
• 16-bit two's complement signed integer
• 16-bit unsigned integer
• 32-bit two's complement signed integer
• 32-bit unsigned integer
• 32-bit IEEE floating point number
• 64-bit IEEE floating point number

asm.js defines the following numeric types:

• int
• signed
• unsigned
• intish
• fixnum
• double
• double?
• float
• float?
• floatish

Original 2011 answer

There is only one number type in JavaScript – the IEEE 754 double precision floating-point number.

See those questions for some consequences of that fact:

• Avoiding problems with javascript weird decimal calculations
• Node giving strange output on the sum of particular float digits
• Javascript infinity object

I would suggest using Buffer.readFloatLE and / or Buffer.readFloatBE to read the required float32 numbers from the buffer.

The example below writes some test float data to a buffer and reads them back. You'll notice the numbers are not exactly equal since we're converting from JavaScript numbers (double-precision 64-bit binary format IEEE 754) to 32-bit floats.

const floatSizeBytes = 4;
const floatCount = 10;

const buf = Buffer.alloc(floatCount * floatSizeBytes);
const testFloats = Array.from({ length: floatCount }, (v,k) => Math.random() * 100);

console.log("Test floats:", testFloats);

for(let i = 0; i < floatCount; i++) {
    buf.writeFloatLE(testFloats[i], i * floatSizeBytes);
}

console.log("Buffer (raw):", buf);

function readFloat(buffer, offset, littleEndian = true) {
    if (littleEndian) { 
        return buffer.readFloatLE(offset);
    } else {
        return buffer.readFloatBE(offset);
    }
}

function bufferToFloatArray(buffer, littleEndian = true) {
    const length = Math.floor(buffer.length / floatSizeBytes);
    return Array.from( { length }, (v, k) => readFloat(buffer, k * floatSizeBytes, littleEndian));
}

console.log("Read back floats from buffer:", bufferToFloatArray(buf, true));

The Float32Array will internally represent the values bases on the endianess of the host system, typically little-endian.

And yes, the format is IEEE 754 (this has been around since before FPUs came along, and the variations of it deals with more the width, ie. 64-bit, 80-bit and so on). All numbers (Number) in JavaScript is internally represented as 64-bit IEEE 754. For typed arrays both 32-bit and 64-bit IEEE 754 is of course available.

PowerPC and 68k CPUs uses big-endian (the way it ought to be! :) ). The so-called network order is also big-endian, and many platform-independent file formats are stored in big-endian byte order (in particular with audio and graphics). Most mainstream computers uses little-endian CPUs such as the x86. So in cases with a combination of these you very likely have to deal with different byte orders.

To deal with endianess you can instead of using a Float32Array use a DataView.

For example:

var buffer = new ArrayBuffer(10240);    // some raw byte buffer
var view = new DataView(buffer);        // flexible view supporting endianness

Now you can now read and write to any position in the buffer with endianess in mind (DataView also allow reading/writing from/to non-aligned positions, ie. you can write a Float32 value to position 3 if you need to. You cannot do this with Float32/Uint32/Int16 etc.).

The browser will internally convert to the correct order - you just provide the value as-is:

view.setFloat32(pos, 0.5);              // big-endian
view.setFloat32(pos, 0.5, false)        // big-endian
view.setFloat32(pos, 0.5, true);        // little-endian

And likewise when reading:

var n = view.getFloat32(pos);           // big-endian
var n = view.getFloat32(pos, false)     // big-endian
var n = view.getFloat32(pos, true);     // little-endian

Tip: You can use a native Float32Array internally and later read/write to it using endianess. This tend to be speedier but it requires a conversion using DataView at the end if the resulting buffer's endianess is different from the host system:

var f32 = new Float32Array(buffer);     // or use a size
f32[0] = 0.5;

Then to make sure you have big-endian representation:

var view = new DataView(f32.buffer);
var msbVal = view.getFloat32(0):        // returns 32-bit repres. in big-endian

Hope that gave some inputs! Just throw me questions about it if you want me to elaborate on some part.

JavaScript's number type is IEEE-754 double-precision binary floating point; it doesn't have an integer type except temporarily during some math operations or as part of a typed array (Int32Array, for instance, or a Uint32Array if you mean unsigned). So you have two options:

1. Ensure that the number has a value that fits in a 32-bit int, even though it's still a number (floating point double). One way to do that is to do a bitwise OR operation with the value 0, because the bitwise operations in JavaScript convert their operands to 32-bit integers before doing the operation:

   | 0 does a signed conversion using the specification's ToInt32 operation:

   value = value | 0;
   // Use `value`...
   

   With that, -5 becomes -5. 123456789123 becomes -1097262461 (yes, negative).

   or >>> 0 does an unsigned conversion using the spec's ToUint32:

   value = value >>> 0;
   // Use `value`...
   

   The latter converts to unsigned 32-bit int. -5 becomes 4294967291, 123456789123 becomes 3197704835.

2. Use an Int32Array or Uint32Array:

   const a = new Int32Array(1); // Or use Uint32Array for unsigned
   a[0] = value;
   // Use `a[0]`...
   

   Int32Array uses ToInt32, Uint32Array uses ToUint32.

   Note that any time you use a[0], it will be converted back to a standard number (floating point double), but if you use the array, depending on what you use it for, it will get used as-is.

Note that there's a method that may seem like it's for doing this, but isn't: Math.fround. That doesn't convert to 32-bit int, it converts to 32-bit float (IEEE-754 single-precision floating point). So it isn't useful for this.

The ES6 standard has Math.fround() which converts a float64 to float32 and then back again, effectively rounding the float to float32 precision. See this article for details.

Replacing the while by this, is the solution:

while (l--) {
    s = Math.max(-1, Math.min(1, samples[l]));
    buf[l] = s < 0 ? s * 0x8000 : s * 0x7FFF;
    //buf[l] = buffer[l]*0xFFFF; //old   //convert to 16 bit
  }
}

Now, the records sounds perfect and the Matlab plots to.

Why not go for Float64? This gives you the most accuracy, and in a toy language I doubt it will have any significant performance difference from the other float types.

Also, you shouldn't name your float type "decimal" unless it is an actual decimal float (as opposed to a binary float), since it will just cause confusion.