play buffer overrun

[Cary B. Cornett]

For a long time I have been getting occasional play buffer overruns in SS (32 bit, which I still use). I would just shrug and hit play again. It's time I did the deep dive to FIX this, but when I try to search for "play buffer overrun" in the help file I get nothing. Where can I find detailed information along with step by step procedures to finally nail this down?

I get this on both my studio and portable systems, with different hardware but the same version OS (Windows 10 LTSC), but I have had this happen with earlier versions going back at least as far as XP.

My studio machine is less than two years old, running a 6 core Ryzen processor, 16 G ram, ATI video, and a MOTU 424 pcie card feeding a 2408 MK III. I have tried large buffer settings but it didn't seem to make a difference (except for more latency, which is a problem when I am using VSTi's in production, and before anyone asks, I render to audio before attempting a final mix).

The session I was running just now that got the error has about 30 tracks and there is no midi or VSTi work involved.

[Bob L]

Pay attention to the MT Load and Src Load readouts during playback... see what the numbers are... a high MT load suggests heavy processing loads... plugins possibly causing this... high src loads suggest issues with disk performance keeping up... or perhaps you are not paying attention to samplerate of the track files and the MT Rate setting... if the tracks are recorded at a different samplerate than the MT is set to, then each track is samplerate converting as the data comes off the disk... this can add substantial loads to the system... especially if the realtime SRC is set to one of the higher options.

Try setting the MT rate to the same as the track files rate.

Bob L

[Cary B. Cornett]

Pay attention to the MT Load and Src Load readouts during playback... see what the numbers are... a high MT load suggests heavy processing loads... plugins possibly causing this... high src loads suggest issues with disk performance keeping up...

The load percentages were fairly low, MT mostly 11 or 12 per cent, maybe peak of 15 or so. SRC load was a bit lower as I recall.

or perhaps you are not paying attention to samplerate of the track files and the MT Rate setting... if the tracks are recorded at a different samplerate than the MT is set to, then each track is samplerate converting as the data comes off the disk... this can add substantial loads to the system... especially if the realtime SRC is set to one of the higher options.

Try setting the MT rate to the same as the track files rate.

Bob L

All track files were at the same sample rate as the session, 44k1.
What else should I look at?

[jmh]

The load percentages were fairly low

Could you have an anti-malware or anti-virus realtime scanning of files? If so maybe sawstudio processes could be whitelisted?

[MMP]

Something is setup wrong on your system if 30 tracks with no plugins is failing.

What buffer setting are you using? How many buffers for input? How many for output?

Are you using ASIO?

What is your hard drive's spec? Have you run a diagnostic on the hard drive?

If you open task manager while running the session sorted by CPU usage, is anything competing with SAW?

In SAW's setup, are you using either of the elevated priority settings?

[mr_es335]

Cary,

I could "remote-in" to have a look-see...

[Naturally Digital]

For a long time I have been getting occasional play buffer overruns in SS (32 bit, which I still use). I would just shrug and hit play again. It's time I did the deep dive to FIX this, but when I try to search for "play buffer overrun" in the help file I get nothing. Where can I find detailed information along with step by step procedures to finally nail this down?

I would look for power saving or throttling settings in the OS and Bios. Perhaps something is going to sleep (not the MOTU) and interfering upon playback. Else maybe something stepping on the audio driver. Have you done DPC latency checker or similar to see if everything is playing together nicely? Try ticking load audio regions to RAM in SAW and see if there's any change. If you don't have system sounds disabled, I'd do so to avoid any sample-rate changing hiccup (even if system sounds are set to a different audio device). Just spitballing...

[Cary B. Cornett]

I have several times now tested session playbacks with Task Manager running to monitor cpu usage. At one point I saw a big spike caused by Windows Compatibility Telemetry. I looked it up, found a procedure to disable it, and did so. I'll need to run more tests looking for another hidden "gotcha".