Use processBlock and audioDeviceIOCallback side by side

Hi,
In my VST audio Plugin, I allow users to select which output audio device to use for outputting audio. The first and default option, is to use Host audio.
So users have two options:
1- Use host audio and let DAW handle the audio (calls to processBlock)
2- Use one of the output devices (calls to audioDeviceIOCallback)

in either of these functions I have some if/else conditions that returns from them if they are not required at that moment, e.g if host audio is not selected processBlock will set the output buffers that is passed to it to zero and returns.

Now here comes my issue:
My default output device on macOS has a IO buffer size of 512. If my DAW’s (Logic Pro for example) buffer size is also set to 512 everything is ok. If it differs then this is what happens:
when the Plugin starts, audio output is set to host audio and audio comes out right. Then user changes to default output device, again everything ok. Then user changes back to using host audio, now the audio that comes out is wrong.
By wrong I mean, if for example host’s buffer size is 1024 then the audio plays back pretty fast. Is DAW’s buffer size is 128 then audio plays really slow.
So it seems using system audio directly and then switching back to using host audio somehow affects the way DAWs interpret the audio.

I am already taking care of the cases where Host’s sample rate and audio’s sample rate are different using LagrangeInterpolator. Should I take special care for different IO buffer sizes?

Sorry if the explanation got too complicated.

I’m pretty sure you’re not supposed to let your plugin talk to the hardware directly… Think about it, if your plugin is set to use audioDeviceIOCallback, how is your DAW gonna bounce any audio thru the plugin when it’s time to render your mix?

Thanks for you reply. When it is set to use audioDeviceIOCallback I do not want DAW to do anything with the sound. That is the reason why I return at the beginning of processBlock when user wants to use one of the output devices.
On the other hand, if Plugin was not suppose to route audio to one of the output devices, then what would be the point of having AudioIODeviceCallback class.

Juce is not only for making plugins but also for making stand alone applications. The AudioDeviceManager/AudioIODeviceCallback stuff is meant to be used for the stand alone applications. It’s a very very bad idea to use those inside a plugin.

You are right, but for my usecase there is no way around it. For some reason I need to directly send audio to the devices. The point is that, talking to audio devices works fine without any problems, but when I switch back to use host’s audio it outputs corrupted audio as explained in the first message.

Couldn’t you really elaborate a bit on that? Why is it necessary for you to directly attempt to access the audio hardware from your plugin? (It generally just isn’t a supported scenario. It might sometimes work, most often it won’t, depending on the host/operating system/audio hardware you are using.)

perhaps if you explain your use-case, someone will know how to do what you’re hoping to do via processBlock()

One of the DAWs we need to support is Adobe Audition. You can see here processBlock function never gets called in Adobe Audition I have posted my problem, that processBlock function does not get called from Adobe Audition and Fabian provided me with a workaround. Unfortunately, our customer didn’t like the workaround and wanted to be able to hear the audio out of the Plugin without any extra effort.
So we decided to create an output device selection combobox. In which the first item is using host audio, and the rest of the options are output devices found on user’s machine.
In all DAWs we select host audio by default, and in Adobe Audition we select default output device, so our user’s problem got solved.
But now we have this combobox that switching back and forth between host and system audio devices causes problem. As said, this is only the case when DAW’s IO buffer size is anything other than 512 (which is my default output device’s IO buffer size).

lol this is that exact instance where the customer is always WRONG!

If you can detect the DAW, maybe force your plugin to only operate in Audition when the buffer size is exactly 512? Otherwise display a “please change buffer size to 512” message. that would be a bandaid fix tho…

Indeed, I think your customer should talk with his customers. Users running advanced DAWs tend to have their routing set up perfectly for their specific gear and wiring. Most of them would hate, if your plugin starts communicating via the systems setup audio device, which can be anything.

However if you insist in doing so, just instantiate your plugin a second time and feed that one to an AudioProcessorPlayer.

HTH

1 Like