Support and General Use > Recording

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

<< < (3/3)

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

Navigation

[0] Message Index

[*] Previous page