Subject: Re: [linux-audio-dev] Audio synchronization, MIDI API
From: Ralf Beck (musical_snake_AT_gmx.de)
Date: Wed Aug 18 2004 - 21:52:52 EEST
Am Mittwoch, 18. August 2004 19:36 schrieb Nelson Posse Lago:
> Quoting Paul Davis <paul_AT_linuxaudiosystems.com>:
> > 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.
>
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.
So which approach is best to follow?
This archive was generated by hypermail 2b28 : Wed Aug 18 2004 - 23:02:31 EEST