3 ms·

2013, so computers >> faster than human hearing so the following probably doesn't matter but devils advocate : memcpy puts stuff in the heap instead of the sta

2013, so computers >> faster than human hearing so the following probably doesn't matter but devils advocate : memcpy puts stuff in the heap instead of the stack, which requires a malloc, a system call, which could introduce some latency. Then layer on that our audiophiles are probably listening to ridiculously high bit rate audio which results in large files, such that without swap buffering there may be some periodic buffer-play-buffer artifacts introduced. This is why you buffer but [new] is also a heap allocation, so same syscall, shouldn't be any different. Is it calloc? calloc in theory should be worse.

mort96 4y ago
Memcpy doesn't allocate stuff on the heap. Memcpy also doesn't care about whether you're copying to/from heap or stack memory (or a memory mapped file, or a memory mapped camera buffer); memory is memory. If the computer isn't able to keep up with the playback, you would probably get extremely obvious sharp clicks, very far from "the sound has a slightly 'hard edge'". New and malloc are identical. Neither one will initialize any of the data. You also wouldn't call either in a loop; you would allocate a buffer once and then copy data into that buffer. You can see this in the code they posted: BYTE *sound_buffer = new BYTE [sizeof(BYTE) * nBytesInFile]; hr = mmioRead(hFile, (HPSTR)sound_buffer, nBytesInFile); That's the only memory allocation in the whole piece of code they posted. They're talking about the audio quality difference between playing audio from a single big buffer allocated by new vs playing from a single big buffer allocated by malloc.