Buffers in Playback Queue?

[Cobus Prinsloo]

Hi, I've wrestled with one project in terms of audio dropouts. It's so bad that, when it happens, it's no use restarting the audio engine.

SO, I've consulted the Sonar manual, and one setting I should be able to change is the number in the Buffers in Playback Queue box under "Mixing Latency".  Although I'm running a decent ASIO driver for my Scarlett 4i4, I'm unable to change the current setting "2".  Can someone help, please?

[David Baay]

That setting is for WDM drivers. It's grayed out when driver mode is ASIO. A project-specific issue is likely plugin-related, but if increasing the ASIO buffer size is not helping, you may have some other issue. When you say "dropouts", is the transport actually stopping with a dropout code, or you're just hearing the audo drop out? An unlicensed/expired plugin on the Master bus could cause this but it would be more consistent.

Next time it happens, try clicking the Audio-MIDI Reset button in the tranport while holding Ctrl to re-initialize the driver.

[Cobus Prinsloo]

No, I get no dropout code. I just hear a pop, and the audio is gone! I'll try that re-initialize option you mentioned. Thank you very much.

[Amberwolf]

AFAIK, in ASIO, all the buffer controls are within the ASIO driver's own control panel, outside of the DAW. 

 

The last time I had an issue (in my ancient SONAR) similar to what you're seeing, it was a misbehaving plugin that I wasn't even actively using--it was in a hidden but not archived empty track.  I don't remember which one, but it was some pitch-bending plugin that stopped working correctly sometime after SONAR6, that I still had buried in my template and forgotten about until this happened.   Why it happened...I dunno--it wasnt' being used, and similar projects had not had this issue, despite starting from the same template, and even another project that was built from the broken project itself after deleting all the clips out of it. 

 

I also once had a problme with a corrupt clip gain envelope that prevented the audio engine from starting, after playback reached it.  The whole program would have to be closed and reopened once that happened, but since it always happenda at the same point it was relatively easy, if very tedious, to find and fix.   

[Bristol_Jonesey]

29 minutes ago, Cobus Prinsloo said:

No, I get no dropout code. I just hear a pop, and the audio is gone! I'll try that re-initialize option you mentioned. Thank you very much.

That sounds like a plugin crapping out.

Have you got anything weir & wonderful in your project? Any freebies?

[Cobus Prinsloo]

5 hours ago, Amberwolf said:

it was a misbehaving plugin that I wasn't even actively using

Your described scenario sounds similar to mine. I suspect it is Spitfire Audio's Albion collection played through Kontakt 8, because it is my first project where I'm using it. But it's a fully licensed VST. I also have to close Sonar, and each time after reopening, the VST is dead -almost dead. The meters still show it playing. If I solo the related track, I can faintly hear it playing. Nothing I try brings it back, and I have to resort to a backup. Truly, bizarre behavior!

[Cobus Prinsloo]

5 hours ago, Bristol_Jonesey said:

Have you got anything weir & wonderful in your project? Any freebies?

I suspect it is Spitfire Audio's Albion collection played through Kontakt 8, because it is my first project where I'm using it. But it's a fully paid and licensed VST. I also have to close Sonar, and each time after reopening, the VST is dead -almost dead. The meters still show it playing. If I solo the related track, I can faintly hear it playing. Nothing I try brings it back, and I have to resort to a backup. Truly, bizarre behavior!

[Amberwolf]

If after closing sonar and reopening, any plugin or synth appears to still be active, ti probably means that plugin has left some memory state open that the reopening of it is picking up.  i don't know if this is possible, but if it is, you might have to flush memory by the os itself before reoopening,  

 

I've not used the tool for a while, but rammap might be able to do this.

 

it could also be something cached for the synth by windows int he prefetch system folder. 

[David Baay]

15 hours ago, Cobus Prinsloo said:

I suspect it is Spitfire Audio's Albion collection played through Kontakt 8, because it is my first project where I'm using it.

Try disabling the 64-bit Double Precision Engine and/or Playback Overampling if enabled for Kontakt.

[Colin Nicholls]

23 hours ago, Cobus Prinsloo said:

No, I get no dropout code. I just hear a pop, and the audio is gone! I'll try that re-initialize option you mentioned. Thank you very much.

I hate it when this happens. Here's my recommendation:

Drag that Latency slider to the right to increase buffers.

Exit Sonar

Re-open Sonar

Open your project and play back. Does this help?

I have seen other programs change the latency so that even if you selected it in Sonar, it didn't 'stick' between sessions.

[Bass Guitar]

2 hours ago, Colin Nicholls said:

have seen other programs change the latency so that even if you selected it in Sonar, it didn't 'stick' between sessions.

I don’t think this is possible. The ASIO control panel rules the buffer setting.  At least that’s been the case for every audio interface I’ve ever used. 
The OP screenshot shows a fairly large buffer setting already. 
It seems like that’s not the issue anyway. 
I’ve always used 256 as my default buffer and will lower it only on the rare instances where I use TH U live when recording. 
If I get audio glitches at 256 then there’s a hog plugin involved. I freeze the offending Synth or if it’s an effect I Bounce the track. 

[Cobus Prinsloo]

11 hours ago, David Baay said:

Try disabling the 64-bit Double Precision Engine and/or Playback Overampling if enabled for Kontakt.

Thanks, that option is checked. I assume it is related to a PC with 64-bit architecture. Should this option remain checked most of the time, and unchecked with certain problem plugins?

[Bristol_Jonesey]

1 hour ago, Cobus Prinsloo said:

Thanks, that option is checked.

The recommendation is to UNcheck it

 

1 hour ago, Cobus Prinsloo said:

it is related to a PC with 64-bit architecture

No, it's related to the internal precision used for calculations

[msmcleod]

1 hour ago, Cobus Prinsloo said:

Thanks, that option is checked. I assume it is related to a PC with 64-bit architecture. Should this option remain checked most of the time, and unchecked with certain problem plugins?

The 64-bit Double Precision Engine has nothing to do with the 64-bit architecture.  It's to do with the precision of audio data during Sonar's internal mixing.

With this unchecked, all audio read from your tracks (or live input) is converted to 32 bit floating point inside Sonar's audio engine.  Once all plugin processing/mixing has been done, it's then is converted back to 16 bit or 24 bit (depending on your audio interface settings) when sending to the hardware outputs.

With it checked, it uses 64 bit floating point instead.

Some plugins however do not work properly with 64 bit audio. 

Fixed point audio (e.g. 16 bit or 24 bit) has an effective ceiling of 0dB.  Floating point however, can go to 100's of dB without ever clipping.

32 bit float has an effective dynamic range equal to 24bit audio, but unlike 24 bit, it maintains this at any volume.

64 bit float has a much, much higher dynamic range.

In practise, 32 bit float should be more than enough.