Recording priority question (Bug?)

[kLyon]

I recently recorded vocals on a fairly CPU intensive project -- vstis, effects, rewire -- and found the resulting track to be full of clicks. Since I had heard nothing of the sort in playback while recording, I went crazy checking out my audio chain: preamp, mic, cables...
Anyway, the upshot is that after exhausting every avenue I changed the soundcard buffer (Lynx C) from 128 samples to 256 and re-recorded: no glitches.
My problem is this: it is a really, really bad thing to have a program give no indication that a recorded file might have glitches due to low latency/cpu workload. No other program I've used will leave you with a corrupted audio file without some indication (usually the file won't play correctly first; in fact, many times a file will be playing back a little glitchy and the recorded track will still be error-free).
In other words, the *last* place for overload to show up should be in a new recording. Perhaps the record priority could be changed, or some indication of impending problems could be made? This could cause serious problems in pressuresome situations.

[Justin]

Originally Posted by kLyon

I recently recorded vocals on a fairly CPU intensive project -- vstis, effects, rewire -- and found the resulting track to be full of clicks. Since I had heard nothing of the sort in playback while recording, I went crazy checking out my audio chain: preamp, mic, cables...
Anyway, the upshot is that after exhausting every avenue I changed the soundcard buffer (Lynx C) from 128 samples to 256 and re-recorded: no glitches.
My problem is this: it is a really, really bad thing to have a program give no indication that a recorded file might have glitches due to low latency/cpu workload. No other program I've used will leave you with a corrupted audio file without some indication (usually the file won't play correctly first; in fact, many times a file will be playing back a little glitchy and the recorded track will still be error-free).
In other words, the *last* place for overload to show up should be in a new recording. Perhaps the record priority could be changed, or some indication of impending problems could be made? This could cause serious problems in pressuresome situations.

Hmm reaper should not have caused those clicks-- some sound card drivers will start losing data when CPU use gets too high, though...

[kLyon]

Thanks, that seems entirely plausible; I just wonder why I never had it happen so tranparently (the lack of transparency, that is) before. Usually the last thing to be affected is the recording process; by the time that happens playback almost always is shot to hell.
It could also be chipset vagaries I suppose: my dual-core amd is nForce 4 and I've heard rumours of problems with that chipset and audio.

[Justin]

Originally Posted by kLyon

Thanks, that seems entirely plausible; I just wonder why I never had it happen so tranparently (the lack of transparency, that is) before. Usually the last thing to be affected is the recording process; by the time that happens playback almost always is shot to hell.
It could also be chipset vagaries I suppose: my dual-core amd is nForce 4 and I've heard rumours of problems with that chipset and audio.

recording is definately prioritized in REAPER.. it is queued immediately during playback and sent to disk whenever possible.

The main thing that should hold true, assuming the audio hardware and driver delivers the recorded data properly, is that as long as playback is fine, the recording should be fine as well.

-Justin

[kLyon]

Thanks for the reply. It's good to know the situation wasn't caused by the program. I don't monitor through software anyway, so 256 samples is fine for recording audio.