Change audio buffer size

Hi, I developing offline plugin and plugin should send audio data to server. After, server send response with processed data and plugin write new samples to audio buffer. But now I have one problem, because server application have minimal audio data size limit (around 2K).
How I can change audio buffer size in plugin? Or maybe JUCE have additional processing function something like: preprocessing audio stream, post processing audio stream?

Plugins can’t control the own buffer size, but that shouldn’t be a problem since you can’t use networking on the audio thread anyway, so there has to be some kind of FIFO. Then it’s just a question of how you deal with back pressure.

Thanks for reply.
When I using multi pass conception (the first pass start thread for write samples to file and then send it to server for processing, second pass read processed samples from file and write it to audio buffer) its work good. But I think this is not comfortable for users. Because I try to find way for do it in one pass.
May be I can use SDK functions directly? For example:

#if AAX_PLUGIN_BUILD
PreRender()
RenderAudio()
// etc
#endif

The prepareToPlay method is called before the stream begins where you can do that work. If you care about idiomatic/“modern” C++ then that should happen in the constructor, along with any other initialization for a single instance.

But what I meant is to pipe data from audio thread to networking thread you need a FIFO or other lock/wait free inter-thread communication technique, and since you can’t count on the size of the buffer to be constant you’ll need to buffer on the networking thread anyway before sending your data to the server, and buffering it when you receive. So controlling the buffer size isn’t really an issue, designing a lock-free channel with back pressure is.

There may be more complexity, as if your plugin is rendering offline (as opposed to real time, I’m not sure if that’s what you meant in your original post), you may need to block the audio callback to deal with network latency.

All told unless your processing can only be done on the server then this idea is very questionable.

Yes, all thread do it work good. When user start playback I starting to buffering all samples. When user stop playback I run processing thread. Its work good. But after that I can’t update samples in DAW, for example, such as in AAX SDK its no problem because I can use PreRender, Render, Post and etc Audio Suite functions. Therefore in AAX SDK I can do it in one pass. I want repeat it by JUCE in one pass.
Now in JUCE this is work good, but only in two pass.

How I try to solve it (what ways):
1 - block audio callback, send data, receive and update samples in audio buffer, but JUCE audio buffer very small (because I wrote my question about it in Topic).
2 - May be JUCE have an additional functions for support of several pass, such as PreRender, Render, etc or may be I can use AAX SDK functions directly in JUCE.

I think your problem is not technical but a design problem. What are you trying to achieve by using server side rendering? If you are developing an application, why not do the processing in the application itself?

Because in host side all implemented. If I will move audio processing into plugin this is can not give the useful effect, because algorithm requred two pass on audio.

But in AAX SDK this is work good, because in Audio Suite mode used several passes. How I understand JUCE can’t give me posibility such as AAX SDK (I means several passes)?
Also may be JUCE have a random access to DAW samples?

It sounds like you’re developing an offline process and trying to shove it into a plugin. The VST/VST3/Audio Unit APIs are intended to be used for real time processes.

When user start playback I starting to buffering all samples. When user stop playback I run processing thread. Its work good.

This is not how plugins are supposed to work. When a user engages playback the plugin needs to compute the output in real time, not buffer and wait to render. There are a few plugins that do things like this, generally they record incoming data and then do stuff in the editor where the user can drag/drop a rendered file to the DAW.

block audio callback, send data, receive and update samples in audio buffer

A plugin that tries to block the audio callback is malformed and invalid. Don’t do it.

If you need networked audio, buffer incoming samples and exchange with a network thread that handles blocking I/O using lock-free mechanisms.

but JUCE audio buffer very small

It isn’t just small, it’s variable and can change between sequential calls. It needs to be treated as unknown, all you know is the maximum buffer size that is specified in prepareToPlay. This isn’t a problem though, you can created a fixed length FIFO/queue structure that can handle up to the maximum buffer size and buffer the incoming samples. There is a little nuance in how you deal with latency and if your network connection can’t keep up, but none of that should happen in the audio callback.

May be JUCE have an additional functions for support of several pass,

What do you mean be “several passes”? The audio callback is continuously called and you are alerted to playback events through prepareToPlay, suspendProcessing, and releaseResources. You even have getPlayHead to return information about where in the playback you are. If you need to go over the same samples more than once then use a loop.

Also may be JUCE have a random access to DAW samples?

No, and the APIs don’t really support that anyway. The closest thing is ARA.

just nitpicking: let’s call it linear processing, since it does also offline bounce (see processor.isNonRealTime())

The juce processor’s are destructive, that means, they replace the original signal with the filtered signal.

The workflow you are looking for is what @Holy_City pointed out ARA (which is only supported by a few hosts) or AudioSuite (ProTools). Have a look, there are people on the forum who managed to use it in connection with juce, but juce itself doesn’t support it out of the box.

Thanks for help! I deep dived to the forum on this theme and seems found that I need AAX_CHostProcessor support.