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

@@ -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 */