Warning 0000002 (split from Re: Internal noise of HDD-based recorders)

[sullen]

I saw that warning 0000002 message tonght recording.  This was my third time with the build I am on, not sure it's late here, and somehow the AGC got turned on for the max of 48db.  I haven't checked the recording yet, just freaked me out with the warning flashing oppoiste the time recorded.  

[petur]

I saw that warning 0000002 message tonght recording.  This was my third time with the build I am on, not sure it's late here, and somehow the AGC got turned on for the max of 48db.  I haven't checked the recording yet, just freaked me out with the warning flashing oppoiste the time recorded.

1) don't hijack threads, start a new one

2) get in touch with jhMikeS on IRC about the warning issue

[jhMikeS]

A few things:

• This build has no patches of any sort?
• It's the latest SVN (post kernel improvements)? Locking used in the disk writing could lag before.
• Was the recording missing even one small bit of data? Warning 00000002 should invariably mean at least one encoded chunk needed to be dumped. If the recording was fine, something else could be clobbering the warnings variable. The AGC thing makes me wonder.
• Disk has sufficient free space and wasn't heavily fragmented?
  

[jhMikeS]

We'll move this to somthing more appropriate of course if discussion continues.

[AlexP]

I've split this from the original thread.

[jhMikeS]

Thanks  

[sullen]

I saw that warning 0000002 message tonght recording.  This was my third time with the build I am on, not sure it's late here, and somehow the AGC got turned on for the max of 48db.  I haven't checked the recording yet, just freaked me out with the warning flashing oppoiste the time recorded.

1) don't hijack threads, start a new one

2) get in touch with jhMikeS on IRC about the warning issue

First, I didn't hijack the thread, it was asked for in the other thread.

P.S. it is worth to note that it was at least once that there was a warning message over timeline in recording screen Warning: 00000002. It didnt affect the output files but since it is not normal if you see this message too leave info here. thanks.

Second, I looked at the two recordings I did at the same time from last night in multitrack in Audition and something is not right.  I was recording two different mic sources and hit start at the same time.  I did the same the night before and they line up perfectly over an hour period with no drifting or issue.  For last night they won't stay lined up no matter what I do, I have to check which has the issue but I figure it was this recording as it was pure analog into the recorder and the other I had an ADC in front of the IRiver only using it to capture bits.  I have no idea when the warning started.  I started the recording, checked the levels, and left it alone for about an hour.

The machine that had the issue:
H140
Rockbox Info - Version r15026-071007

1. When I saw the warning, I hit record to start a new file in case it was some sort of write issue.  I didn't want to lose what I already had.  
2. I was able to pull both files off of the unit through copy/paste.  
Build has no patches.  The only thing out of the ordinary would be that I installed a new build for the first time on this unit, then copied files from an old build (font folder,etc.) onto the new build, and then I think I upgraded to the current build on my machine with copy/paste replacing the original recent build, more recent build files/folders that it wanted to replace were replaced.
3. Plenty of free space, recently formated before installing above builds.  I am not sure about the exact build/load order because I did the same with my H120 after swapping hard drives as I think the original was going bad.  
4. I did not have any AGC engaged the first 3 recordings I made with this machine.  I think I accidently turned the AGC on when adjusting the levels on the recording right before the recording at issue.  

If there is anything else I can provide answers to, let me know.  

EDIT: Thinking back on it a few minutes, I can't put the blame for the alignment issue on the build.  I was using an ADC in front of the the unit without issue which is a different part of the chain.  With the first night, both units were going analog all the way into the unit with the unit handling the ADC part.  I don't see anything missing from the recording, but haven't sat down to listen to it all the way through with headphones.

[jhMikeS]

Should we start some sort of logging that logs the time index (down to the sample) where the problem(s) occurred? I guess you could seek right to the purportedly affected area then to examine it. Some recording buffer would be the cost as I wouldn't want to completely rely on it being written to disk in case that fills up. It is doubtful it would ever log many problems. I guess it would be possible to view the log from memory and flush it only if absolutely required. RB does have similar functionality in logf but that enables tons of stuff in tons of places that I wouldn't want in a normal build.

Nonetheless, a somewhat elaborate feature to do up and just an idea banging around in my head atm.

FYI: r15134 was when the scheduler improvements were introduced which gets rid of alot of nasty latencies in the kernel. It is very snappy with thread waking and latencies that are only microseconds whereas before things were sort of sloppy and they could reach many milliseconds - unacceptable in a semi-RT app like this. Only one minor issue had shown up since then  that I have been made aware of and it is now fixed and only affected dual-core targets (which are obviously more complex) and only at initial boot. It was more of a minor annoyance.

I'm frankly not aware of any recording bugs after the second big update that really were traceable to recording code itself. It has come from threading implementation bugs (except for the disk full issue) in the kernel and believe me I've made sure to think hard about it and slay them since real problems there can cause problems for any and every part of the system.

I suggest a newer build after said revisions and the inevitable post-big-commit tweaks. Use pre/post if you don't feel comfortable with an updated kernel just yet.

[petur]

I'm working on gain logging, maybe the warnings can get logged there too...

Nothing ready to show though - low on time atm

[bugg100]

I also have seen this error on a 140.  Not sure which build as I am not sure if I've updated rockbox since then.....  I'll check for version and report back here.

On the recording I got the error on, the problem that I found is that the recording has a period that is not recorded.  No glitch or popping, just basically playback sounds normal then is from different time...  Maybe I should post a sample?

I didn't report this because I haven't been able to reproduce it.

Joe

[jhMikeS]

A not recorded segment is what you'd expect whether it's 45ms (one-frame glitch) or several seconds (big glitch) depending on how long output buffer space was unavailable. I imagine the pcm buffer could be used as backup storage (avoid encoding for a bit) if output is full but even that will fill if disk writing won't give.

The latest builds should get rid of priority inversion effects when accessing the disk (a cheap but very effective thread kick for now). I suspect some background disk operation on a low-priority thread may have been responsible.

[jhMikeS]

Just had a conversion with Toki and his troubles don't seem related to recording bugs at all. Toki was testing PCM Wav, 44kHz in parallel with me on the same, unmodified 60GB X5 model I have with extremely different outcomes. Both running unpatched late SVN builds.

My results:
PCM Wav 44k, or even 88k consistently flushed out from the time of initial spinup to the end of HD spindown in about 4 seconds. No chance it would overflow like this. My unit is in good, working order.

Toki's results:
Rather random. Sometimes 4 seconds, sometimes 30 seconds or more. No way should WAV ever take that long (not even WavPack, 88k takes that long). Was having consistent trouble on almost every flush. Even reported that it got this warning during prerecord. This is impossible to get (overwrite of oldest is a normal prerecord condition and does not produce that warning) so I suspect a nearly full buffer (within a chunk or two) at the time of the stop. Dying HD? Terrible fragmentation? Nothing can be done by the recording system about that but that will produce output overflows.

When stopping (outlined just for fun  ):
New data coming from the source is blocked, a flush immediately done, a wait for any residue to encode (a few chunks at most is possible), a mark of file end, then another flush if an encoder added a few more chunks to the previously empty buffer (only mp3 actually does this step to flush the filter banks). The file is then closed. Incoming data is unblocked if prerecord time is not zero.

[petur]

I have had weirdness in the past (even before the new codec framework) and attributed it to limited hdd space on a fragmented disk. I had 6GB free and that was clearly too much fragmented. A format fixed it all