18 Aug
2004
18 Aug
'04
11:43 p.m.
On Wednesday 18 August 2004 02:52 pm, Ralf Beck wrote:
Am Mittwoch, 18. August 2004 19:36 schrieb Nelson
Posse Lago:
Well there is Moore's law *ducks*
Quoting Paul Davis
<paul(a)linuxaudiosystems.com>om>:
Hm, so there are two ways to do remote processing:
1. jack over ethernet
Would use a server application (jack client) on the host that provides
jack ports and sends the data over ethernet.
Pro: You can bundle several audio streams and send them in a single
package. Con: If you want to control remote plugins from your host
application, you need an additional application doing the same for the
ladspa parameters.
2. ladspa over ethernet
Here a pseudo ladspa plugin would send the parameters and audiodata over
ethernet (something like ladspavst is doing for vst plugins on the local
host).
Pro: On the remote machines all you need is a plugin manager, which could
even be
a pseudo host for audiounit plugins on a Mac or VST host for VST plugins on
a WinXP machine, that
does the ldspa->vst/au wrapping, or a true ladpsa manager on a linux
machine.
Con: Sending data for each single plugins produces more overhead and
thus takes up more cpu power on the host.
wrong model. a given jackd has a single driver.
a new jack client,
sure.
I believe the way to do this is to have one remote jackd with a driver
that sends/receives data through UDP and one local jack client that
interacts with this remote server.
There is something like this already, I believe (haven't checked):
http://www.alphalink.com.au/~rd/m/jack.udp.html
As a side note, the system I developed intends to do this over ladspa;
more on this on another message.
> oh, and a small correction. VST System Link has basically nothing to
> do with networked audio. [...] it does *not* distribute audio
> across the network at all. So which approach is best to follow?
Who's to say we couldn't have both? The former sounds like virtual MADI
and would be better for streaming capture to a disk array (I didn't think
about that at all so maybe not)