next topic »

[on:]

I noticed this in arduino-1.5\hardware\arduino\sam\libraries\Audio\Audio.cpp

Code:

buffer = (uint32_t *) malloc(bufferSize * sizeof(uint32_t));

Sadly, memory allocation has bugs at present. Boilerplate:

Please note that, at present, the String library has bugs as discussed here and here.

In particular, the dynamic memory allocation used by the String class may fail and cause random crashes.

Does this use of malloc imply that Audio will have he same issues that the use of the String clas has at present? Or does the C compiler and library used on the SAM architecture not have those issues? (And if not, does that mean String is also safe to use, on Due?)

[Reply #1 on:]

I didn't make deep tests about malloc to verify the fragmentation problem, so i don't know if we'll have the same String issues.
What i can say for sure is that in many months of tests i didn't had any issue with it.

In any case, Audio library does only one allocation at the moment of instantiation of the Audio object, so it should be safe even with a buggy malloc.
C

[Reply #2 on:]

In any case, it isn't malloc() that is the problem in the AVR libs, it's free(). So if you malloc(), but never free(), there shouldn't be issues.

[Reply #3 on:]

C, pico, thanks for the responses.

The Audio library does use free:

Code:

void AudioClass::end() {
dac->end();
free( buffer);
}

although it is not clear to me if that destructor is ever called, due to the setup+infinite-loop Arduino program structure.

[Reply #4 on:]

Strictly speaking, this is not the destructor, but a method called "end", so you can call it explicitly using

Code:

audio.end();

in your sketch.