Support and General Use > Recording

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

<< < (2/3) > >>

jhMikeS:
Thanks  :D

sullen:

--- Quote from: petur on October 24, 2007, 03:40:00 AM ---
--- Quote from: sullen on October 24, 2007, 01:07:58 AM ---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.
--- End quote ---

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

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

--- End quote ---

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

--- Quote ---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.
--- End quote ---

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page