FS#4754 - Iriver hangs after longer recording with voice enabled

Attached to Project: Rockbox
Opened by Toni (ahellmann) - Tuesday, 28 February 2006, 21:06 GMT
Last edited by Peter D'Hoye (petur) - Sunday, 30 April 2006, 19:17 GMT
Task Type Bugs
Category Recording
Status Closed
Assigned To Peter D'Hoye (petur)
Operating System Iriver H100 series
Severity High
Priority Immediate
Reported Version
Due in Version Version 3.0
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


I found a problem with current recording and voice enabled on my iriver
with a custom build based on 20060226 dailies.
After investigation I think it is related to the audiobuffer system of
the audio codecs.
My theory:
If the audiobuffer gets completely filled with audio data
(t-record > 2min) the pcmtable descriptors of the audio thread get
overwritten. For some reason these now corrupted descriptors seem to
be accessed by the voice audio decoder after leaving the recording screen,
which makes the player hang.
In my experiments the problem started, if pcm record data is written
up to 200-400 Bytes near audiobuffer end. Because the current recording
pcm chunk size is a multiple of 8192, the chance is big, to get no trouble.
But to my understanding the audio buffer start address is flexible so
sooner or later there will be a problem with the current dailies.

my theory is based on this structure in pcmbuf.c
/* ...CODECBUFFER|---------PCMBUF---------|GUARDBUF|DESCS| */

This task depends upon

Closed by  Peter D'Hoye (petur)
Sunday, 30 April 2006, 22:30 GMT
Reason for closing:  Fixed
Additional comments about closing:  it was in fact two bugs:
- the recording buffer overlapping the voice buffer
- recording should always notify the others it used the buffer
Comment by Matthias Mohr (aka Massa) (mmohr) - Thursday, 27 April 2006, 14:47 GMT
Does this bug still exist in newer CVS versions?
Do you have uptodate voice files?
Comment by Toni (ahellmann) - Thursday, 27 April 2006, 15:14 GMT
Did not check yet. I can try early next week.
Comment by Peter D'Hoye (petur) - Thursday, 27 April 2006, 21:14 GMT
unable to reproduce this on a h340 (which uses the same code)...
Comment by Peter D'Hoye (petur) - Sunday, 30 April 2006, 19:12 GMT
Right. This is a clash between voice and recording, both using the same buffer. The bug is only triggered when pre-recording is off, because then the recording system doesn't notify the rest that it is using the buffer (SWCODECS only). However the recording code for SWCODECS always uses the buffer.

Fix pending...