Details

The memory allocation for the thumbnail buffer (used for .talk clips) previously assumed that the start of the audio buffer would not move, but if used with other features (notably dircache) this is not true. This resolves bug #5662.

This patch updates talk.c to properly allocate a fixed thumbnail buffer (up to 32K, should be plenty). It also updates audiobuf properly when a voice file is loaded.

Note, I have tested this on H300 device and simulator. I have not tested it on a HWCODEC device, but the bug should still be fixed on such devices. It would be good if someone with a working Archos could give this a test though.

Here's an updated version that only implements this change on SWCODEC configurations. Other (i.e. Archos) devices regularly switch between mp3 and .talk clip playback, calling reset_state() and so keeping pointers in sync, so no crash will occur. This version works the same but will not use up 32K on Archoses; only downside is it uses #if statements.

OK, here's take 3 - this one still only affects SWCODEC. It uses buffer_alloc to allocate memory and allocates the thumbnail buffer up-front (no dynamic cleverness that could cause a crash). This is in talkbufferfix3.patch. Once this is applied, the application of allowtalkduringplay.patch will enable voicing via .talk clips during playback (on SWCODEC). This last part in particular needs testing on Archos - somebody - please...!