Fix recorderv2 manual.

archosrecorderv2 uses the archosfmrecorder manual.

Change-Id: I015272db750b2fc5054d8259b37f00e0698afbff
Update changelog.

Change-Id: I81491530d712fde8cc0912d4ede26ce1db55a6df
Support GIMP bmp files.

Change-Id: I7380ceeaf696b67e1641d24e7b932e3d74770932
Fix warning and re-order code a bit.

Change-Id: I1d733b3d0bd17cc541218f9a2b7712712ad314dd
Fix errors introduced by a62bd92.

Change-Id: I3f65ca5347d08e1b77196c73ccb3a0951f14c850
buflib: Try harder in buflib_alloc_maximum().

This function will now ask shrinkable allocations to give up all of their
memory. With future support of playback.c this can be used as a safe
replacement for audio_get_buffer().

Change-Id: I290a51d2c75254e66baf5698c41dc444dea6247a
buflib: Add buflib_context_relocate().

This function relocates a buflib back buffer, updating pointers in struct
buflib_context. It does not move any data by itself.

The intended use-case is buflib-on-buflib, where a buflib back buffer is
allocated with buflib and attempted to be moved. The move_callback() can call
this and return BUFLIB_CB_OK on success. No move_callback() is called for the
subordinate buflib buffer, therefore it must not contain non-movable
allocations. The caller is generally responsible moving the data and all its
implications.

Change-Id: I869219f9cff786a172c9e917a5f34470073892e6
playback,talk: Share audiobuffer via core_alloc_maximum().

This fixes the radioart crash that was the result of buffering.c working
on a freed buffer at the same time as buflib (radioart uses buffering.c for the
images). With this change the buffer is owned by buflib exclusively so this
cannot happen.

As a result, audio_get_buffer() doesn't exist anymore. Callers should call
core_alloc_maximum() directly. This buffer needs to be protected as usual
against movement if necessary (previously it was not protected at all which
cased the radioart crash), To get most of it they can adjust the willingness of
the talk engine to give its buffer away (at the expense of disabling voice
interface) with the new talk_buffer_set_policy() function.

Change-Id: I52123012208d04967876a304451d634e2bef3a33
fix some reds.

Change-Id: Iecb1305dbd1519434e0f476d2199e728b96091f9
hwcodec: Need to grab audio buffer before recording.

This was missed in 22e802e because I didn't realize that hwcodec doesn't
compile pcm_record.c.

Change-Id: I48cd4c2beec0a3d01caf06f2a2ced98be22a3673
Fix yellow.

Change-Id: Ib46e4d0896de4227a508abf5806c00ec3d59db51
Fix more reds.

Change-Id: I13e9a0398efe0dab222f2a9c4f5d9295570e4dfd
Merge branch 'master' into lab-general
Proposed fix for FS#12878: Zero-length embedded album art prevents mp3 playback

see http://www.rockbox.org/tracker/task/12878

Change-Id: Ib4233c06e18d1d193dfb9e73e745ca5d174e40b2
Reviewed-on: http://gerrit.rockbox.org/507
Reviewed-by: Michael Giacomelli <giac2000@hotmail.com>
Reviewed-by: Thomas Martitz <kugel@rockbox.org>
lcd: Fix scrolling.

Change-Id: I1f8d3d67b224c1c531438b94e3aab640b76770be
hwcodec: core_alloc_maximum() returned 0 bytes if talk.c controls the audio buffer.

On hwcodec talk.c has the entire audio buffer (not just parts of it), therefore
it must give up everything and cannot count on core_alloc_maximum() to return
the remaining space. This is equivalent to it was handled before 22e802e.

You could probaby do smarter and shrink for example the .talk clip buffer
but is it really worth it?

Change-Id: Idc3431c59fb41b05338559c615093358c5d8ed9b
recording: Fix sloppy return value check. This caused an OOM panic.

Change-Id: I30bbc5623d81ad7cbbee52a439fb5909af2761b7
Merge branch 'master' into lab-general