播放wav文件后，是否需要删除缓冲区？

Question

I am trying to implement classes implementing the wav playing, as explained in this example . The relevant code part is here :

/* Setup for conversion */
wav_cvt.buf = malloc(wav_len * wav_cvt.len_mult);
wav_cvt.len = wav_len;
memcpy(wav_cvt.buf, wav_buf, wav_len);

/* We can delete to original WAV data now */
SDL_FreeWAV(wav_buf);

/* And now we're ready to convert */
SDL_ConvertAudio(&wav_cvt);

When a wav file finishes playing (I am not going to play it again), do I need to free the memory buffer that is malloc()-ed above? Or is it done automatically somewhere?

Answer 1

No, nothing is done automatically. You must free it.

Answer 2

Remember that C (and anything of it's implementation) doesn't manage dynamic memory allocation automatically, whenever you have allocated some pieces of memory (mark the memory offset as USED), you should free() it when you are done to remark that offset as UNUSED. But that's not MUST!!!.

Answer 3

Any malloc is generally free 'd elsewhere by the same module. I say generally because you may never intend to give the memory back for performance or persistence reasons. Furthermore, memory allocations will be reclaimed by the operating system when the process terminates regardless You're not endangering the system.

Since you malloc ed the buf, you should actually free it yourself. Save SDL_FreeWav for wave buffers passed to you by SDL that you are done with (such as from SDL_LoadWav ).

Internal to SDL_LoadWav , will be a malloc call by SDL. SDL_FreeWav is a wrapper around the corresponding free . This allocate/deallocate function pairing is common as some libraries may implement custom memory management routines that resemble or wrap malloc and free . They may even open up new heap contexts that are not accessible from the standard functions, and intended to be private. There's not even a requirement that the memory be allocated on a heap, but this is orthogonal to your question.

It's likely that SDL_FreeWav is just a straight free , but when a library provides deallocation functions you should prefer those in case the behaviour differs.

When in doubt, always call the deallocation routine if you believe you're done with the memory resource. Double free errors are noisy and generally generate stack traces that will let you quickly identify the problem. Other libraries such as glib will usually have built-in diagnostics that will alert you to overzealous deallocation. Deallocating aggressively also aids in locating logical errors: If you think you're done with the memory, but some other part of the program isn't, the resource use will need to be re-examined.