Cakewalk hides audio drop outs and tries to glue the silence. Can I disable it?

[Wojtek Stecyszyn]

Hi Cakewalkers

Im testing new interface and facing some drop out issues. What I have noticed is that when a dropout occurs while recording (a one second cut off in audio) CbB is then glueing the gap and tries to go on with recording as it never happens. The glue point is sometimes good, stitch less and you would not tell that there was a cut in audio, but more often it is not prefect - has a pop in it and many times the audio clip is moved and thus out of sync with the rest ot the tracks. Anyway I don't want CbB to hide the audio cut - need to see exactly where and when audio drop out happened to pin point the cause.

It happens on my both interfaces:

Tascam US-144mkll with its dedicated ASIO driver latest version

Steinberg UR44C - with Yamaha Steinberg USB Driver latest version

 

To explain: because the dropouts are happening very rarely its a time (hours, days) consuming task to spot them. Therefore I just leave the recording session ON when I go for lunch, or for a nap, or anything and then when I come back I analyse the recorded waveform to check if the audio drop out happened. I was fooled till this day that I have no more dropouts because the audio waveform was constant and with no cuts, and assumed that the issue is gone. Only today a drop out happened when I was recording my tracks! I was wrong and wasted many days because I didn't know then that CbB is hiding these cuts!! I still have drop outs but it again takes days to spot them - I would have to sit hours while testing it by recording and listening for the cuts - this is the only way now that i have. I have no time for that, and I cant do it while working - recording serous stuff because I cant allow any drop outs while recording material. I whish I could leave recording ON leave it and then just check the waveform.

 

It happens on my both interfaces:

Tascam US-144mkll with its dedicated ASIO driver latest version

Steinberg UR44C - with Yamaha Steinberg USB Driver latest version

 

SPECS:

Windows 11

Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz 2.11 GHz

16.0 GB RAM

SSD 1TB

Edited September 28 by Wojtek Stecyszyn

[David Baay]

I've rarely encountered a dropped buffer while recording but when it does happen, that buffer will simply be missing from the file, and the next successfully processed buffer will effectively be butted up against the last buffer with no gap. This generally creates a disconuity in the waveform that will manifest as a pop unless the sample level at end of the previous buffer and the start of the next just happens to be very close to the same and trending in the same direction. But if there's a noticeable sync issue with other tracks, that would suggest that it's more than a single, small buffer getting lost. If you're running an exceptionally high buffer like 1024-2048 samples for reliability and/or recording more than one track, you might actually get better results with a smaller buffer size or you might need to increase your Record (disk) I/O bufferin Preferences to accomodate that. Depending on the criticality of the recording, you might also conseder lowering the dropout tolerance so that recording just stops rather than continuing on with no indication of a problem.

See this post of more info:

 

[Wojtek Stecyszyn]

10 hours ago, David Baay said:

I've rarely encountered a dropped buffer while recording but when it does happen, that buffer will simply be missing from the file, and the next successfully processed buffer will effectively be butted up against the last buffer with no gap. This generally creates a disconuity in the waveform that will manifest as a pop unless the sample level at end of the previous buffer and the start of the next just happens to be very close to the same and trending in the same direction. But if there's a noticeable sync issue with other tracks, that would suggest that it's more than a single, small buffer getting lost. If you're running an exceptionally high buffer like 1024-2048 samples for reliability and/or recording more than one track, you might actually get better results with a smaller buffer size or you might need to increase your Record (disk) I/O buffer in Preferences to accomodate that. Depending on the criticality of the recording, you might also conseder lowering the dropout tolerance so that recording just stops rather than continuing on with no indication of a problem.

Now that is a piece of valuable information and good suggestions. Thank you!

Yes I had my buffer set to max 2048 thinking that this will put the lowest load on my CPU and was doing my tests by recording two-three tracks at once (clean project with no plugins). But my Record I/O Buffer Size was also high - 1024. 

BTW is it OK to adjust the RECORD and PLAYBACK I/O buffers separately, so they have different values? Or they have to be the same?

Yes, I would like to have real dropout with notification and code - that would be very informative. What do you think would be good value to decrease dropout tolerance?

 

[David Baay]

Yes, disk I/O buffers can be set independently. I've frequently raised my playback buffer to accomodate high track counts (mostly in 3rd-party projects as my own aren't generally that dense), but I'm seldom recording more than a couple tracks at a time in my own use so don't need a large record buffer. The disk side of things has all become less critical with the advent of SSDs, and it's usally pretty clear whether a dropout was due to a CPU or disk shortfall.

I've never personally had occasion to mess with dropout tolerance so can't really say what's ideal in a given situation, and this stuff tends to be very system-specific so you might just have to experiment.

 

[Wojtek Stecyszyn]

Thank you @David Baay I will do my test

[mettelus]

On 9/28/2024 at 6:19 AM, Wojtek Stecyszyn said:

What I have noticed is that when a dropout occurs while recording (a one second cut off in audio) CbB is then glueing the gap and tries to go on with recording as it never happens.

This one is puzzling to me because of the duration. A full second gap being stitched together seems like the clock signal isn't being utilized from the audio stream (and is butting received buffers end to end like David mentioned). One of the bakers would need to chime in on the mechanics of this for more details. I have never seen this occur, but I am very curious as to the why.

[Wojtek Stecyszyn]

21 minutes ago, mettelus said:

This one is puzzling to me because of the duration. A full second gap being stitched together seems like the clock signal isn't being utilized from the audio stream (and is butting received buffers end to end like David mentioned). One of the bakers would need to chime in on the mechanics of this for more details. I have never seen this occur, but I am very curious as to the why.

I say its sometimes even 2 seconds gap of total silence.

Why this is happening?  Great question. My first assumption might be my recent upgrade from win 10 to 11. I had long years of successful uninterrupted playback and recording on win 10  and recently I decided to do the leap nad go up to win 11. This is first thing that comes to my head and perhaps (Im not dure though) only change I made to my studio recently. I read that win 11 especially on Dell's laptops (which I have) do have issues with DPC latency and so I can see on both LetancyMon and DCP Latency Checker apps that I have some spikes that might be the cause. Last weeks I was doing what I could to help it and reduce it and now its gone down to much lower values. This with many other tweaks (Windows settings, BIOS, Registry, many drivers update, CbB tweaks) I guess I managed to improve the situation. At the span of 3 days I had only one audio cut - today during recording test - it was very short. Maybe half of a second. 

[mettelus]

@Jim Roseberry might also have insight on this at a system level. DELL and HP have a tendency to run proprietary drivers, but I am not sure with the what/where, or how they would relate to Win11. Have you tried testing using WASAPI Exclusive mode? If there is a rogue driver in play, that may cut it out of the loop.

[David Baay]

I hadn't really registered how long the gap is. A gap that big seems more like some sort of unreported file-writing error. DPC spikes or anything else causing the buffer to run dry would usually cause a full dropout with the transport stopping long before that. I'm pretty sure the DropoutMsec parameter applies only to playback and that the tolerance for recording is much smaller or even zero (i.e. even a single empty buffer will cause an instantaneous recording dropout). FWIW, I have a Dell laptop with Win11 that's prone to DPC spikes but have not encountered anything like that. One thought: If you've enabled Write Caching at some point in your attempts to gain reliability you might actually want to disable that; it's not always helpful in my experience.

[Jim Roseberry]

With a laptop, you're dealing with a lot of performance throttling and power-management.

Neither are good for a high-performance DAW scenario.

First thing I'd do is check DPC Latency.

[Wojtek Stecyszyn]

12 hours ago, David Baay said:

One thought: If you've enabled Write Caching at some point in your attempts to gain reliability you might actually want to disable that; it's not always helpful in my experience.

Write Caching (as well as Read Caching) is disabled as it always was.

 

7 hours ago, Jim Roseberry said:

First thing I'd do is check DPC Latency.

Im doing it regularly each day after every change and tweak in my settings. 

LatencyMon usually shows well known ACPI.sys (ACPI Driver for NT) spiking about 1300μs in DCP and 147.5 μs in ISR in a span of several minutes (very rarely go red) but yesterday first time I saw i green (below 1000) for more than 9min - that's the best score I aver had so far.

Second app DCP Latency Checker two day ago I managed to bring down to around 500μs when laptop is idle.