Details
When running AAC decoding on the DM6446, the file starts playing just fine but
after a while I stop hearing anything, always at the same point and tried it
with different media files, same result every time. Nevertheless, the pipeline
does not crash with any error message, the file seems to be playing but after
enabling debug level 5 on TIAuddec1 I get to see that it gets stuck in some
point with no error log as mentioned.

After this point the pipeline gets stuck and I'm forced to terminate it using
Ctrl+C.

Details
When running AAC decoding on the DM6446, the file starts playing just fine but
after a while I stop hearing anything, always at the same point and tried it
with different media files, same result every time. Nevertheless, the pipeline
does not crash with any error message, the file seems to be playing but after
enabling debug level 5 on TIAuddec1 I get to see that it gets stuck in some
point with no error log as mentioned.

It looks like the circular buffer is getting stuck -- the write pointer can't
reset to the beginning of the buffer because it is not in the last window. The
circular buffer is asuming that it will never receive an input buffer larger
than a window. That is not true in this case.

There is code in the circular buffer that allows it to processes input bfufers
in smaller pieces so this doesn't happen, but right now the code only kicks in
durin the encode use-case. I'm looking at this further.

This problem has actually existed for awhile, but was never exposed until we
corrected the circular buffer allocation for the audio elements in trunk@369.

I've attached two patches that should resolve this issue. I consider the fix
moderate-risk, as it affects the functionality of the circular buffer queueing
mechanism. However, I consider this issue pretty severe, and I believe a
moderate-risk fix is worth it in this case.

This fix modifies the circular buffer to always copy part of the input buffer
if there was space available. This was previously only done for
encode. Also, it no longer assumes that calls to gst_ticircbuffer_shift_data()
will always succeed.

I have sanity-checked these patches on OMAP3. I've played-back elementary AAC
audio streams, transport streams, AVI and .MP4 files, all without issue.