From 5827e41904b2e3de7d5b7e53a8e55f35197e1add Mon Sep 17 00:00:00 2001 From: Thomas Martitz Date: Tue, 24 Dec 2013 01:16:10 +0100 Subject: 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 --- apps/talk.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/apps/talk.c b/apps/talk.c index 9343661181..8979952103 100644 --- a/apps/talk.c +++ b/apps/talk.c @@ -875,6 +875,11 @@ bool talk_voice_required(void) /* somebody else claims the mp3 buffer, e.g. for regular play/record */ void talk_buffer_set_policy(int policy) { +#if CONFIG_CODEC != SWCODEC + /* always grab the voice buffer for now */ + (void) policy; + give_buffer_away = true; +#else switch(policy) { case TALK_BUFFER_DEFAULT: @@ -882,6 +887,7 @@ void talk_buffer_set_policy(int policy) case TALK_BUFFER_LOOSE: give_buffer_away = true; break; default: DEBUGF("Ignoring unknown policy\n"); break; } +#endif } /* play a voice ID from voicefile */ -- cgit v1.2.3