This is fantastic. Would it be possible to make it cross platform? I like using Logic on my MacBook, but have an AMD 3900x sitting around too which I'm currently not using for audio. I was looking into running vsti's on it as a slave and just routing audio back and forth, but would it be possible to use it for distributed DSP directly?
Well, as AudioGridder is using JUCE, many parts of the code are cross platform already. But there is some parts of the network code as well as the screen capturing and keyboard/mouse code in the server, that is OSX specific. I would expect the efforts to add support for other platforms to be reasonable. So I hope there will be interested developers, that could have a look at this.
This is really cool! This is kind of a cloud CPU version of Universal Audio Apollo which offloads on local DSP chips.
What's the lowest latency achievable in practice? I'd be surprised if you can run anything under 50ms, so it's probably limited to mixing use-cases, which is already really cool because that tends to be the "plugin-heavy" phase.
How does it work in terms of licensing for the plugins that run remotely? I'm not familiar with common licenses used by plugins.
You can get below 50ms. But yes, the intention building this was mixing.
You can start with no additional buffering In AudioGridder. The additional latency on top of your configured I/O latency (based on the I/O buffer size in your DAW) will be the network RTT plus DSP processing time of one sample block.
The lower the latency the more fragile the setup will be. That’s why you can add additional buffering in AudioGridder.
Surprising that this makes sense rather than just doing the processing locally or on the GPU. What kinds of filters are people using that are this intensive?
GPUs may be used more and more for usage outside of graphics, but they don't lend themselves very well to audio, in particular recursive filters which are very common.
This requires experimentation. On my network I get around 1-5ms rtt. It’s a 1gb ethernet giving around 100mb/s throughput. So I’m _usually_ able to work with an I/O buffer size of 512 samples which is ~23ms at 44,1khz and no additional buffering in AudioGridder. Larger projects with many channels or complex plugin chains probably require larger buffer sizes.
These have existed for a long time. They used to be called sound cards and maybe still are, I've been calling them audio interfaces for the last decade, and getting what you need in this space is an exercise in defining your actual requirements, because there is no standard for what's important and what's not. A good one can do wonders for latency when doing a lot of DSP.
Can you describe a little better what this box's purpose would be (scenarios most relevant to the development becoming a commercial success), because a cursory glance at the real-time audio part of Max/MSP (and the Pd (Pure Data) fork/clone) suggests that specialized audio DSP hardware would not be beneficial, compared to using a CPU/distributing it over multiple cores, or potentially even a GPU.
I was talking to avid. But their “business“ model does not seem to support open source. I have AAX support, but they do not provide me with the signing tools required to sign AAX plugins to get them loaded by protools production builds.
[+] [-] dharma1|6 years ago|reply
[+] [-] apohl79|6 years ago|reply
[+] [-] mochomocha|6 years ago|reply
What's the lowest latency achievable in practice? I'd be surprised if you can run anything under 50ms, so it's probably limited to mixing use-cases, which is already really cool because that tends to be the "plugin-heavy" phase.
How does it work in terms of licensing for the plugins that run remotely? I'm not familiar with common licenses used by plugins.
[+] [-] apohl79|6 years ago|reply
You can start with no additional buffering In AudioGridder. The additional latency on top of your configured I/O latency (based on the I/O buffer size in your DAW) will be the network RTT plus DSP processing time of one sample block.
The lower the latency the more fragile the setup will be. That’s why you can add additional buffering in AudioGridder.
[+] [-] pjc50|6 years ago|reply
[+] [-] audioguy13|6 years ago|reply
[+] [-] WalterSear|6 years ago|reply
[+] [-] bjt|6 years ago|reply
[+] [-] apohl79|6 years ago|reply
[+] [-] brandonmenc|6 years ago|reply
[+] [-] IggleSniggle|6 years ago|reply
[+] [-] namibj|6 years ago|reply
[+] [-] rectang|6 years ago|reply
• Absolutely minimal latency.
• Ability to run open source software.
• Stackability (to achieve high horsepower via multiple units)
• Multichannel digital i/o (analog is unnecessary, there are lots of great hardware AD and DA converter units)
• Wordclock
There's plenty of cycles in modern chips, but latency is a killer with native CPU processing.
Alternately, I'd love a RTOS which could run open source software on high-horsepower multi-core CPUs.
[+] [-] diydsp|6 years ago|reply
ah,here's the current model, Pacarana: http://www.symbolicsound.com/cgi-bin/bin/view/Products/Pacar...
[+] [-] qppo|6 years ago|reply
[+] [-] kitotik|6 years ago|reply
I wonder how/if it handles latency compensation when used with other plugins.
[+] [-] apohl79|6 years ago|reply
[+] [-] jazzido|6 years ago|reply
[+] [-] kitotik|6 years ago|reply
[+] [-] musiccog|6 years ago|reply
[+] [-] esilverman|6 years ago|reply
[+] [-] apohl79|6 years ago|reply
[+] [-] kamonrye|6 years ago|reply