EXOVERB plugin complains about Cakewalk settings, while working fine on my own VST3 host...

[Sunshine Dreaming]

I installed EXOVERB MICRO and activated it. Then in Cakewalk it shows an error screen (left on the screenshot), complaining about some settings, although they seem all to be met!? Sample Rate is at 44.1kHz in my project, and for buffer sizes Audio->Sync & Caching->File System->Playback I/O  I tried 8, 256, 512 in the settings menu, always same error.

But when I open it with my own VST3 host it works fine (see right in the screenshot):  

The plugin has VST3 SDK 3.7.2.

My own VST3 host (using VST SDK 3.7.9) used a buffersize of 512 samples.

I use Cakewalk 2023.09 (075); Windows10Pro 22H2 (build 19045.2846); 

I sent the link of this topic thread already to the support of Dear Reality.

 

Mixing Latency is 441 Samples; Could that be the reason?  EXOVERB MICRO expect a buffer size with a power of 2;  441 is not such a size. I also installed the "EXOVERB MICRO Additional Samplerate Support". However, I use 44100kHz Sample Rate, so it was not expected, that that additional samplerate package would change anything; and it didn't.

I cannot change that button, its grayed :

 

Edited November 8, 2023 by Sunshine Dreaming

[Xoo]

441 is indeed not a power of 2 (2, 4, 8, 16, 32, 64, 128, 256, 512, 1024...).  It's expecting to be used with an ASIO driver which (almost always) has a power of 2 buffer size.

[Sunshine Dreaming]

11 minutes ago, Xoo said:

441 is indeed not a power of 2 (2, 4, 8, 16, 32, 64, 128, 256, 512, 1024...).  It's expecting to be used with an ASIO driver which (almost always) has a power of 2 buffer size.

Thank you for your answer.

I just checked it with the VSTPluginTestHost using the  Steinberg ASIO (in-built driver) from the VST3 SDK. Also there it gives that error message,

But when I switch that test host  to "Jack Audio Router" it also works without complaining as in my own VST3 host, which is built from that same SDK.

Edited November 7, 2023 by Sunshine Dreaming

[John Vere]

You could try changing your on board audio settings in Windows Sound Settings. All my on board audio can be set to use 48/24 which is better for compatibility with movies etc.  

Then if you use WASAPI exclusive mode you can change your buffer settings.  
This is possibly a good reason to purchase an audio interface which would not be as limited as using on board audio. 
Instructions for how to do this : 
 

 

Edited November 7, 2023 by John Vere

[Sunshine Dreaming]

1 hour ago, John Vere said:

You could try changing your on board audio settings in Windows Sound Settings. All my on board audio can be set to use 48/24 which is better for compatibility with movies etc.  

Then if you use WASAPI exclusive mode you can change your buffer settings.  
This is possibly a good reason to purchase an audio interface which would not be as limited as using on board audio. 
 

Thank you for your answer. An audio interface is no option. And Cakewalk was already on WASAPI (Shared).  There it has 441 samples.

When switching it to MME it also failed, switching it in Cakewalk to ASIO now works; It uses 512 samples (Mixing Latency) then! It then uses the JackAudio Router (which must be active externally)  Without any Windows Sound Settings changes.

Setting Cakewalk to Exclusive WASAPI indeed sets it to 512 samples. And it works. Thank You!

But setting Cakewalk back to Shared WASAPI unfortunately also sets it back to 441 samples, although I can change the sample rate; but 441 samples even on 48000Hz...

The setting for Shared WASAPI seems to be wrong, why would it always switch back to 441  samples?

When building the "RenderSharedEventDriven" Sample from the Windows SDK the buffer size is on default 480 samples, so there is no API restriction to 441 samples. Seems to me more to be a bug within CbB

As you suggest in your video I've set 24bit 48000Hz in the Windows Sound settings for my output device. Makes no difference. After restarting CbB now the Shared WASAPI mode shows 480samples... (not a power of 2)

 

After your suggestion in the video to deactivate "Allow applications to take exclusive control of this device"  CbB gives this error:

and if I click "use anyway" then np sound output...

Edited November 8, 2023 by Sunshine Dreaming

[Sunshine Dreaming]

When calling IAudioClient::GetDevicePeriod in the "RenderSharedEventDriven" Sample from the Windows SDK, it returns: 
defaultDevicePeriod: 100000
minimumDevicePeriod: 26667

devicePeriodInMSEC = defaultDevicePeriod / (10000.0);  = 10msec  this leads to 441 samples on 44.1kHz

devicePeriodInMSEC = minimumDevicePeriod / (10000.0);  = 2.66.. msec  this leads to 117 samples on 44.1kHz

Forcing that sample count to 512 in the RenderSharedEventDriven Sample works fine. So there's no restriction and during that test playback also another media player correctly continues to play (because its "shared" WASAPI).

Edited November 8, 2023 by Sunshine Dreaming

[Byron Dickens]

3 hours ago, Sunshine Dreaming said:

An audio interface is no option.

Say what?

[Sunshine Dreaming]

7 minutes ago, Byron Dickens said:

Say what?

This topic is not about interfaces, this is about a bug in CbB, which could be easily corrected.

Wasting resources for devices people (like me) do not need is never a good idea, especially when its a software bug, which I simply can avoid in my own VST3 host...

[Glenn Stanton]

maybe it's something that the WASAPI doesn't like about the virtualized IO using Jack? https://jackaudio.org/ i've seen a number of products which require an "even" boundary on the samples in order to operate (e.g. 441 does not work for a specific VST, but 512 does). 

[John Vere]

13 hours ago, Sunshine Dreaming said:

This topic is not about interfaces, this is about a bug in CbB, which could be easily corrected.

Wasting resources for devices people (like me) do not need is never a good idea, especially when its a software bug, which I simply can avoid in my own VST3 host...

Actually your issue is directly related to your audio system because any system that doesn’t support 48/24 is garbage. 
I use on board audio from time to time on another desktop and a laptop and I use 48/24 and I can use both WASAPI modes .  
 

Either you on board sound chip is junk or that 3rd party app for routing is crap.  They usually are. 
 

Cakewalk was designed to be used with ASIO drivers and this is only available with proper audio interfaces.  People can try and fight it but you won’t win.  On board audio if set up correctly can be all some people need, but with limited use Like next to impossible to record audio properly.  

The most important part of a recording chain is the pre amp and the converters. The input on a computer has got to be the bottom of the food chain for that.  

Edited November 8, 2023 by John Vere

[Byron Dickens]

13 hours ago, Sunshine Dreaming said:

This topic is not about interfaces, this is about a bug in CbB, which could be easily corrected.

Wasting resources for devices people (like me) do not need is never a good idea, especially when its a software bug, which I simply can avoid in my own VST3 host...

It's not a bug. It's you trying to use some substandard bootleg garbage instead of proper equipment..

Funny how nobody with a real audio interface set up correctly has problems like this....

[Starship Krupa]

17 hours ago, Sunshine Dreaming said:

Setting Cakewalk to Exclusive WASAPI indeed sets it to 512 samples. And it works. Thank You!

Why does this discussion continue after this point?

You got it to work.

Now you're claiming that there's a bug in Cakewalk and someone else is suggesting that your onboard hardware CODEC may be "garbage."

WTF?

Cakewalk and Exoverb Micro work together when you configure Cakewalk to use WASAPI Exclusive, which is the preferred driver mode for onboard sound. What is there to say beyond that point?

[Sunshine Dreaming]

2 hours ago, Starship Krupa said:

Why does this discussion continue after this point?

You got it to work.

Now you're claiming that there's a bug in Cakewalk and someone else is suggesting that your onboard hardware CODEC may be "garbage."

WTF?

Cakewalk and Exoverb Micro work together when you configure Cakewalk to use WASAPI Exclusive, which is the preferred driver mode for onboard sound. What is there to say beyond that point?

You're right the hardware side is out of the scope of what I said. And it sort of works with some caveats (Exlcusive only and also running the Jack Audio Router additionally).

WASAPI Shared is not limited to a certain sample count and its unnecessary that its grayed in Cakewalk. So whatever you want to call it. To me that is an issue or a bug. Enabling that slider would solve it.  I did not say more than that that restriction is not based on a limitation of Shared WASAPI, since I successfully can use different blocksizes in different WASAPI apps at the same time.

And I just found this older post, where that problem obviously also was raised:

 

Edited November 8, 2023 by Sunshine Dreaming

[Sunshine Dreaming]

Ok, I got an answer from the plugin vendor support. They said, I should tryout ASIO4ALL. And thats a known issue with Cakewalk.

I had ASIOLink installed. But I don't know how to use that. 

So I will tryout ASIO4ALL.

 

Edited November 8, 2023 by Sunshine Dreaming

[Glenn Stanton]

ASIO4ALL is a wrapper for the WDM drivers - so it might work as you can adjust the ASIO4ALL buffer size.

EXOVERB, per their user guide is restricted to:

Supported sample rates by installation: 44.1 kHz, 48 kHz and 96 kHz
Download reverb files for additional support: 88.2 kHz, 176.4 kHz and 192 kHz
Supported buffer sizes: 32, 64, 128, 256, 512 and 1024

i use ASIO4ALL when an older softsynth needs even boundary buffers (which EXOVERB requires)

the SHARED WASAPI is itself limiting to "best" buffer size in a shared usage. ASIO, EXCLUSIVE WASAPI, etc all being full control have the option to give the active app the control to adjust the buffer. 

so not a "bug" in either product, just an unfortunate intersection of restrictions due to your IO HW.

[John Vere]

The fact that WASAPI Shard mode doesn't offer buffer adjustments is 100% on Window and your Audio systems end. It has nothing to do with Cakewalk.  

This is why if you are using on board audio and want ASIO type features and performance you use WASAPI Exclusive mode.  That is as close as it will get.  

ASIO4all is really only WDM mode in a 3rd party wrapper. This is why Cakewalk staff do not recommend it. Any Vendor that does is really out of touch with Windows 10 and 11 audio realities and I would personally avoid their products.  Asio4all= WDM mode is the old Windows code and worse performance than WASAPI shared. Sure it might work but you'll  just keep digging a deeper hole. 

Reaper uses a completely different audio engine than many DAWs do. 

[Sunshine Dreaming]

ASIO4ALL sets the buffersize to 512 and the plugin runs correctly, without the need of running an external service. 
Rendering to an audio output file succeeds (The plugin does not silence the track anymore). And other WASAPI players can continue to play, but yet the live audio output is not configured. Although the VU meters show the audio level, the soundcard does not yet output any sound. 
I think I'll find a way also for that. but I don't think I need it, cause:

Then I found FlexASIO 1.9. The buffer  size can be set in a configuration file "FlexASIO.toml" (although I installed also FlexASIO.GUI, the UI does not open on my system  and after another reboot it finally opens) and as backend WASAPI is used. Both settings Shared and Exclusive are supported. I chose "Shared" and finally it works!  Also a bigger project plays in the same way now as it did on "WASAPI Shared" before. EXOVERB MICRO loads correctly in Cakewalk, no error message/warning.  Even a media player continues its playback while CbB is playing through  "flexASIO". Increasing the blocksize to 2048 improved the sound quality. I never do live recording with CbB anyway, for that I use another DAW, but also there an USB microphone does not need any interface. And if I want to use an external keyboard that also would use USB.

This might not be a solution for everybody. Those who do recordings from a non-digital source might need an interface, I would never doubt the experience of those people. But if you only have digital input (like me) or stems or USB microphone and 3.5" cable monitor speakers  with own amplifiers  (and there are good ones) and an external sub woofer,  for what do you then need that additional device? So no energy is wasted for an additional device, when finally WASAPI Shared works with this setting.

For those who are interested how to set it up: on default it uses (the preferred) 882 samples and the slider in CbB is enabled, but the setting is not applied... mmh, I heard a similar problem somewhere before...), but it can be set in the configuration file; You might need to change the device name to your audio device name; that you can find through running C:\Program Files\FlexASIO\x64>portaudiodevices.exe  And you can test your configuration outside CbB by running C:\Program Files\FlexASIO\x64>flexasiotest.exe

Here the C:\Users\<your username>\FlexASIO.toml:

# Use WASAPI as the PortAudio host API backend.
backend = "Windows WASAPI"
bufferSizeSamples = 2048

[input]
# Disable the input. It is strongly recommended to do this if you only want to
# stream audio in one direction.
device = ""
suggestedLatencySeconds = 0.0
wasapiExclusiveMode = false

[output]
device = "Lautsprecher (High Definition Audio Device)"
channels = 2
suggestedLatencySeconds = 0.0
wasapiExclusiveMode = false
 

Thanks for your help and insights.

 

 

Edited November 10, 2023 by Sunshine Dreaming

[Bruno de Souza Lino]

3 hours ago, John Vere said:

The fact that WASAPI Shard mode doesn't offer buffer adjustments is 100% on Window and your Audio systems end. It has nothing to do with Cakewalk

Explain how you can set it on REAPER then.

[John Vere]

I did already. 

[Starship Krupa]

13 hours ago, Bruno de Souza Lino said:

Explain how you can set it on REAPER then.

It's because REAPER is different. Cakewalk could be different too, but making Cakewalk different is a feature request.

I've seen other programs that do or do not allow setting buffer size for WASAPI Shared. I imagine that the companies that make it fixed do so with the idea that the fixed number of buffers that they use is a good compromise between playback latency and leaving enough resources available to other programs that are playing sound at the same time.