18 Aug
2004
18 Aug
'04
3:51 p.m.
Quoting Paul Davis <paul(a)linuxaudiosystems.com>om>:
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.
If I understood it correctly, yes it does, but their concept of a
"network" is somewhat weird: it allows you to send data from one
machine to the other for remote processing, but it uses the
digital audio ports of the soundcards of the machines to pass
the audio data around (together with other data). Therefore, it
only works with audio cards with digital I/O and word clock.
See ya,
Nelson
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
18 Aug
18 Aug
6:12 p.m.
New subject: [linux-audio-dev] Audio synchronization, MIDI API
Am Mittwoch, 18. August 2004 19:36 schrieb Nelson Posse Lago:
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.
So which approach is best to follow?
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.
11:43 p.m.
New subject: [linux-audio-dev] Audio synchronization, MIDI API
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)
19 Aug
19 Aug
2:49 a.m.
New subject: [linux-audio-dev] Audio synchronization, MIDI API
On Wed, 2004-08-18 at 21:27, John Check wrote:
BZZT, wrong. This kind of thinking leads to having to upgrade every few
years just to have it not be any faster (but more features!). Moore's
law is NEVER a valid excuse to do things in a sub-optimal way just
because you don't have time to do it right.
That kind of attitude is why gnome-terminal on a modern machine is
sluggish compared to xterm on a P200.
Lee
Con: Sending data for each single plugins produces more overhead and
thus takes up more cpu power on the host.
Well there is Moore's law *ducks*
4:27 a.m.
New subject: [linux-audio-dev] Audio synchronization, MIDI API
On Thursday 19 August 2004 12:35 am, Lee Revell wrote:
On Wed, 2004-08-18 at 21:27, John Check wrote:
BZZT, wrong. This kind of thinking leads to having to upgrade every few
years just to have it not be any faster (but more features!). Moore's
law is NEVER a valid excuse to do things in a sub-optimal way just
because you don't have time to do it right.
Heheh, well I _ducked_ because on more than one occasion when I brought up
off loading softsynths and FX to another host, I got Moore's law as a
rationale for not worrying about processor power. I mentioned the corollary
you allude to in yesterdays post.
Con:
Sending data for each single plugins produces more overhead and
thus takes up more cpu power on the host.
Well there is Moore's law *ducks*
That kind of attitude is why gnome-terminal on a modern machine is
sluggish compared to xterm on a P200.
Not a big fan of GNOME. I have a p200 laptop with 40Mb and I had to set up an
NFS share just to have room to install it. Same laptop with "the other"
desktop ran (slow, but it was usable when everything was loaded) and had
enough free disk to not step on roots reserve.
Whatever works for you is my motto
Lee
18 Aug
18 Aug
8:54 p.m.
New subject: [linux-audio-dev] Audio synchronization, MIDI API
On Wed, Aug 18, 2004 at 02:36:10 -0300, Nelson Posse Lago wrote:
It doesnt neccesarily require word clock, it depends if the card can sync
to its digital i/o ports or not.
Th reason they do this ofcourse is so they can bypass the whole
synchronisation nightmare and avoid resampling everything.
- Steve
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.
If I understood it correctly, yes it does, but their concept of a
"network" is somewhat weird: it allows you to send data from one
machine to the other for remote processing, but it uses the
digital audio ports of the soundcards of the machines to pass
the audio data around (together with other data). Therefore, it
only works with audio cards with digital I/O and word clock. 
19 Aug
19 Aug
2:03 a.m.
New subject: [linux-audio-dev] Audio synchronization, MIDI API
Steve Harris <S.W.Harris(a)ecs.soton.ac.uk> writes:
On Wed, Aug 18, 2004 at 02:36:10 -0300, Nelson Posse
Lago wrote:
Synchronizing the A/D converters can also eliminate certain phase and
jitter problems that might otherwise occur. You definitely wouldn't
want a pair of stereo channels coming in over differently-clocked
converters, for example.
--
joq
If I understood it correctly, yes it does, but
their concept of a
"network" is somewhat weird: it allows you to send data from one
machine to the other for remote processing, but it uses the
digital audio ports of the soundcards of the machines to pass
the audio data around (together with other data). Therefore, it
only works with audio cards with digital I/O and word clock.
It doesnt neccesarily require word clock, it depends if the card can sync
to its digital i/o ports or not.
Th reason they do this ofcourse is so they can bypass the whole
synchronisation nightmare and avoid resampling everything.
7199
days inactive
7200
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
6 participants
participants (6)
-
Jack O'Quin -
John Check -
Lee Revell -
Nelson Posse Lago -
Ralf Beck -
Steve Harris