Access to the audio device from a plugin

Is there a way to route audio to the audio device from a vst plugin?

flow-plugin

I want to do something like this (pseudocode):

bufferFromDaw = getAudioBuffer()
sendToAudioDeviceInput1 (bufferFromDaw)
bufferFromAudioDevice = getFromAudioDeviceOutput()
bufferFromDaw = bufferFromAudioDevice

Thanks.

That is a functionality your host provides. It is not available for plugins.
You route a track to a physical output into your outboard, and route it back to record into a new track.

I suspected it, but nevertheless I found this: https://www.kvraudio.com/product/vst_interfaced_asio_host_by_christian_budde

It’s possible to attempt all kinds of things, but it doesn’t mean the things will work well.

2 Likes

Even if your audio driver allows multiple programs accessing the device (which you shouldn’t take for granted), the two programs have no guaranteed way of running synchronous…
so something will run, but the results are unpredictable…
If you plan to base a product around that, hire enough support people… :wink:

2 Likes

It’s not my intention to work perfectly, it’s to run some hardware analysis, but I guess it will be better to do it from the host, but I have no idea how to do it

This host I have programmed without knowledge of how to make a host, so it may be very badly programmed, but it works perfect to analyze my plugins.

In the host audio loop:

void MainContentComponent::getNextAudioBlock (const AudioSourceChannelInfo& bufferToFill)
{

    bufferToFill.clearActiveBufferRegion();

    // Clear the buffers
    for (int i = 0; i < filterManagers.size(); ++i)
    {
        filterManagers[i]->setAudioBufferSamples (4, bufferToFill.buffer->getNumSamples());
        filterManagers[i]->getAudioBuffer()->clear();
    }
    
    if (analizer != nullptr)
        analizer->preProcess(); // send analizer test signal to the buffer

    // plugins
    for (int i=0; i < filterManagers.size(); i++)
    {
        filterManagers[i]->processBlock();
    }
    
    if (analizer != nullptr)
        analizer->process(); // fill processed buffers to display analysis
}

showing you this code you will realize why I was asking to do this from a plugin.

1 Like

If you just want to analyze external hardware, doing your own audio app is going to be the easier way to go. Trying to do it from a plugin inside a 3rd party host by accessing the audio hardware directly isn’t going to work reliably.

However, if the host has suitable routing options of its own, you might be able to utilize those facilities. For example, you could develop separate plugins to do the analysis signal generation and analysis steps. For example : have the signal generator on one track, and make that track’s output go into the audio hardware. Then have another audio track with the analyzer plugin that receives the processed audio from the hardware. This however can get quite complicated if the signal generator and analysis plugins need to share data. Making your own stand alone application would at first thought seem to be the simpler solution.

If the host audio interface is different than the audio interface you want to connect to from inside the plugin, it will be a non-trivial task to resample the audio correspondingly in the plugin (since you’re dealing with multiple clocks).

Perhaps writing a “standalone” JUCE app will make the job more straightforward, because then you have direct access to the soundcard.

I will do it from the host (a juce app) now I will see if there is any more “abstract” way to interconnect channels.

Thanks guys!