Support and General Use > Recording
WARNING: current CVS recording code not stable [ NOW FIXED! ]
jhMikeS:
Just got done listening to 2h 14m 25s of flawless wav recording with a voice file present and AGC safety clip. Voice restarted in the menus as expected and no crash.
Thought I had a glitch at 1:09:23 but it turned out it was just the words f***in nothin' censored in a odd way (Metallica). F***in nothin' about summs it up though.
Petur: I can send you the 1.32GB file to prove it if you like. :) Have you considered isolating your DAP from vibration? I don't doubt the recording environment must be kinda loud. Just a thought.
What I hear in your recording is exactly the sort of thing that should happen if it writing is blocked and the output fills: it _must_ drop data since it has nowhere to put it.
I suggest a lengthy recording in a quiet envoronment like just recording radio with your usual setup. If that is ok, try recording with the DAP and speakers in a box and cranking up the volume to a concert level with the corresponding low end. See what happens.
These long recordings mean a lot of trips around all the buffers and you got five glitches and I got none. I would expect something to show up for me if the recording itself were faulty but I'll keep an open mind. This problem could be unique to the H300 series but that would rule out recording itself since aside from SPDIF the code is identical to yours.
The crashes at stop are certainly another issue (since all data is written including the headers which are the very last thing updated before closing a file) as is the AGC crash (DivX0) reported elsewhere.
Sorry for being repetitve but I want my analysis well documented. ;D
mlind:
How about recording a sine wave or something equally constant?
This way a glitch will probably be clearly visible.
How long is the drop-out? A few samples or a few seconds?
A serious test would be to record with the DAP lying still for a period of time, and then be moving in some disturbing way for an equal amount of time, and so on back and forth with the different circumstances well documented for comparison with the recorded result...
jhMikeS:
The skips petur had are exactly on chunk (2048 sample) boundaries and clearly discernable, both by ear and in my audio editor at the sample level. Any skips in the radio recording would be too but nothing. The DAP was still for the entire time when I tested. Inability to flush data will drop the latest data and keep the codec write position from overrunning the read (where disk writing start) position. Not preventing that would just crash it and destroy the markers for file starts and ends.
EDIT: I should also mention that all skips were forward in time, not random or backwards which is the correct behavior for the inability to write to disk for some reason recording would have no control over.
petur:
except for the last two where 2 seconds recording was saved twice...
fyi, I've done many recordings (over a year time) in the same conditions or even worse (too load, too much bass so more vibrations). Never had a glitch. The problems started after the new recording framework was committed though the first recordings were fine.
My bet is more on disk fragmentation. I've defragged now and will try to keep it that way.
pabouk:
--- Quote from: MikeS on December 05, 2006, 04:12:18 AM ---Inability to flush data will drop the latest data and keep the codec write position from overrunning the read (where disk writing start) position.
--- End quote ---
Just a little idea: Could not the buffer dropping event be logged using logf to be able to narrow down possible reasons of the glitches?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version