Support and General Use > Recording

WARNING: current CVS recording code not stable [ NOW FIXED! ]

<< < (6/11) > >>

pupil:
just a quick question, been following the problems you're having with recording recently. What is the last dated CVS build that you would recommend installing if (like me) you are wanting perfect recordings without these reported glitches.

thanks.

jhMikeS:

--- Quote from: pabouk on December 05, 2006, 12:06:18 PM ---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?

--- End quote ---

It already does.

EDIT: And I've never seen the message logged even running WavPack at 88.2 which requires a thread priority boost (in addition to CPU boost) to flush. The prio boost causes almore instant completion of data writing.

jhMikeS:

--- Quote from: pupil on December 05, 2006, 01:08:34 PM ---just a quick question, been following the problems you're having with recording recently. What is the last dated CVS build that you would recommend installing if (like me) you are wanting perfect recordings without these reported glitches.

thanks.

--- End quote ---

I don't think you'll have any problem with the latest. As I said, I did a concert length recording on my H120 and had not a single skip.

The only possible output buffer full glitch would be from the file apis being unable to write. There is no issue with any encoders being able to keep up with the data on the input end. WAV and AIFF never boost at any samplerate, even 88.2 kHz.

petur:
just found a way to make it freeze:

from the rec screen:
- pres rec to start recording
- press stop
- press rec again while still flushing
*bingo*

jhMikeS:
I can't get it to do it (freeze permanently that is). It just sticks for a second or two then just stops recording as it should. These are just the sort of operations I performed when preparing the update but will look further. The recording screen probably isn't quite set up for asynchronous stops. The H120 has no RTC and create_datetime_filename might have something to do with it since it waits until the next second before returning the file name. My x5 is in the shop so I can't test this with the RTC :-[.

While stopping, the state is still "recording" so the record button should be requesting a file split.  The split should be rejected in audio_new_file because the stop should be waited for first and you can't do audio_new_file if not already recording.

Navigation

[0] Message Index

[#] Next page

[*] Previous page