Windows Audio WAVEFORMAT buffer BYTE to 16-bit int
This doesn't seem to be very good code, and it certainly isn't well commented to explain why it is doing what it is doing.

To answer your question at the "*****  WHAT'S GOING ON HERE  *******" mark:

1) The "* 2" in the chunk.size calculation is clearly because the data is assumed to be stereo.

2) Each sample value is a 2 byte int (16 bit), the chunk needs to have chunk.size samples.

3) The multiplier is to compensate for the memcpy working differently on different platforms.  A char may be one or two bytes,  memcpy moves char sized pieces.  It used to be strictly bytes, but that isn't the case with this code.  This problem would be more efficiently solved with a global DEFINE.

4) The memcpy copies the data from the input buffer to the storage location

5) The loop looks for a silent chunk, allowing a little tolerance -1 to 1 is silent.

Now, here is why I think this is poor code:


For ordinary audio, there are going to be a heck of a lot of Log messages generated.
If it is non-zero (not silent) the chunk will be kept (pushed onto the queue).  If logging every value isn't needed, the loop should break as soon as the chunk is determined not to be silent
The logic of zeroing 1s and -1s in a kept chunk makes no sense to me
If the chunk is not kept, the chunk.chunk array is not deleted (assuming the kept chunks are deleted downstream).  This is a memory leak.


That's enough for now, hope it was helpful.

Ced