Rockbox

I encountered probably the same bug. Yesterday I recorded about 10 mono WavPack files from external microphone using the latest build. It crashed twice. One crash was after pressing stop (after 4 minutes of recording) the second one appeared after starting the recording. The message was like:

error I05:
at <some hex number>

Rockbox recovered from the crash after pressing PLAY.
I will investigate more to write down the exact debug message.

Which player? It must be coldfire based. The actual hex number might be quite helpful. Please take a note of it if you encounter this again. Looks to be a divide-by-zero exception if I read the CF data correctly. A descriptive string should be added to the list.

On an unrelated subject, I tried playing Doom a few times and had crashed with I00 (in menus). It was fine before. Perhaps some recent change destablilized things somewhere.

BTW: I have been doing mostly programming and practically no running of rb of late and something really could have changed which I've been "away".

It was on iriver H120.

I made it to crash again after stopping the recording on the current built 060909-1036.
The message is different:

I40:PDIR1FULL
at 000000D4

I attached my settigs. I did not make it to crash with the settings cleared.

I also encountered other crashes when leaving the "Recording Settings" menu entered from the FM Radio screen.
I described it in this bug report: http://www.rockbox.org/tracker/task/5963

Added comments to http://www.rockbox.org/tracker/task/5963.

You shouldn't need to create a new bug report each time with related items.

Excuse me. I thought it should be considered as a different bug.

I did some more recordings using the build 060909-1036 on iriver H120 and I got the following crash messages in the Recording Screen (WawPack, mono):

- before or during recording (every 2nd try)

I40:PDIR1FULL
at 00000005

I40:PDIR1FULL
at 00000008

- after stopping the recording (once)

I40:PDIR1FULL
at 000000D3

I think I have a pretty good idea why and that it would we WavPak over others is not too suprising. WavPak in particlar uses the largest chunks of data and since peaking (for the peakmeters) is done in the DMA1 handler, it's spending too much time peaking instead of pulling samples from the FIFO so the FIFO gets full resulting in the exception you keep getting. The FIFO in the ColdFire is only 6 samples long or about .000136s worth of audio.

What I don't understand here is why Mono in particular or do you just mostly record mono files? Channel mixing is done in the codec itself so DMA1 should still run.

Mono is just a coincidence I have just one microphone so I welcome and use the mono option.
I did not test it with stereo neither with other codecs (MP3, WAV). I will test these options too.

Do I understand it correctly that the selected codec can cause the crashes even before starting the recording (with prerecording turned off)?

No prerecording still has the codec running all the time so it could still do it. I'm gonna move the peaking code out of the DMA1 and add handers for those error on my next update. The only time it currently doesn't add samples from DMA is when paused. I'll try calculating peaks just when they're asked for and on the most recent data since most of the peaks it calculates aren't even used.

I do not know if it is related to the original bug but I still observe problems while recording.
This time I tested recording radio to WavPack, WAV and MP3 on iriver H120.

The builds around 060915 stopped the recording spontaneously instead of a crash (WV,WAV,MP3 320kbps). It seems that stop was more frequent with higher bitrate. With WV stereo it stopped mostly after 50 seconds of recording up to 10 minutes. With MP3 192kbps it did not stop.

The builds after the 17 Sep 18:52 change do not stop recording spontaneously anymore but there are other problems:

- Often the harddrive writing is very log with WV (I have seen 7 minutes). During the writing it behaves normally but the file size value on the display is not updated. The recorded file is often corrupted. There are lost samples during the start of HDD write or the file ends shortly after the time of beggining the HDD write. WAW does not seem to have this problem.

- With WV the first HDD write is after 18.7 MB and sometimes the following intervals are much shorter (like 5 MB). With WAV the first HDD write is after 25.9 MB!

(1) In current CVS it is possible, that the whole file writing is done in cpu unboosted state. So the 7min perectly make sense if you keep in mind, that the cpu has to do compression in parallel to the file writing. => Can be improved easily.

(2) file writing after 18.7MB:
This is true, because to my understanding of the WVPACK algorithms, there is no real worst case compression rate. The encoder uses the 25MB as if there is no compression available. => Can be tweaked, if there is a worst case compression rate on wavpack. (say 1200kbit/s?)

(3) writing after like 5MB:
This is again related to the slow writing. When the recording has finally finished with writing, the buffer may be already near full again. => automatically fixed, if (1) is fixed

1) Dang...I forgot to change that to always boost the CPU for writing. I'll change that one.
3) ^^
2) Would WVPACK actually produce a larger output than the pcm size? If so, the encoder doesn't take the WavpackHeader into account if the compressed data is the same size as the pcm data.

More on point 2:

From http://www.wavpack.com/397/wavpack_doc.htm:

For "worst case" files (those with very high level, noise, or distortion) WavPack may actually create a .WV file slightly larger than the original .WAV file, and this will be indicated as "negative" compression. Some lossless compression programs (like WinZIP) detect this case and simply store the data without compression. However, since I have not actually seen a real audio file do this, I have decided not to go to the extra trouble of handling such a case and besides, even if this happens, the .WAV file will still be correctly restored.

I have the latest CVS build on H120 and the serious problems are gone. Thank you.
This thread could be probably closed?

Some more comments regarding the early buffer flushing when using WavPack:
* When I record WavPack in mono it starts to write the buffer about 13 MB.
It should not be so much worse than stereo WavPack probably.

* I would like to explain you my idea how the buffer flushing should work.
Let's say that RB needs to start writing 5 seconds before filling the buffer.
- 5 seconds is 862 kB with CD Audio bitrate 1.4112 Mbps.
With WAV Rockbox starts flusing at 25.9 MB it would mean that the buffer size
is approximately 26.7 MB.
- Let's say that the WavPack's worst case is 1.6 Mbps. It is 977 kB during 5 seconds.
It means that Rockbox should start writing when the buffer is filled to 25.7 MB (26.7 MB - 977 kB).
It would still have 5 seconds to relieve the buffer in the worst case.

* It seems to me that Rockbox starts flushing the buffer according to the number of read samples
(recording time) not according to the actual fulness of the buffer with output from the codec
like in my idea I described above.

Yes, the flush is currently based on pcm samples processed and not encoded data so I'm not suprised that the buffer would flush at half of what it should with mono since the codec does the downmixing.

Could anyone close this task please? I think that the problem with crashes is resolved. I can fill a new bug report for the early buffer writing if needed.