Subject: Re: [linux-audio-dev] RFC: API for audio across network -inter-host audio routing
From: Nelson Posse Lago (lago_AT_that.com.br)
Date: Sat Jun 15 2002 - 11:01:12 EEST
On Thu, Jun 13 2002 at 11:55:11am +0200, Men Muheim wrote:
> > http://magic.gibson.com/
> Looks interesting. Thanks for the info.
> [...]
> The discussion here should not be about the network but about an audio
> API which is independent of the underlying network stack.
> [...]
> I think the first thing to do is to define an audio API that reflects
> network capabilities and design the according audio library / server.
> Maybe the server could base on some of the JACK technology. Only after
> that the "network driver" comes into place.
Hi,
I think what I intend to do is somewhat related to this. I'm not sure if
what you are talking about are systems for synchronous or asynchronous
data transfer. As for asynchronous, I suspect that (as pointed out by
Steve Harris) MAS and RTP are good starting points.
I intend to write (RSN - I turned it into a school assignment) a "remote
effects processor": suppose I'm running a JACK graph where I have a lot of
LADSPA plugins running, and I want to add another one but my hardware
can't keep up; I'd like to be able to offload some of the work to another
machine. So, I'll create a host that simply grabs the data fed by jack,
sends it to be processed on a different machine, gets it back and feeds it
back to jack. To achieve this, we simply send the data during one jack
"cycle" and receive the processed data on the next "cycle" (which would
mean add something to the total latency). I want this to work over
ethernet, probably with UDP.
This would be a proof-of-concept implementation. If it works, I'd like to
implement a more general idea to do this on top of JACK, maybe even a
patch to JACK; this would allow us, for instance, to have all the UI work
done on one machine, all the disk I/O work done on 2-3 other machines, all
the DSP work spread over a bunch of machines and all the audio I/O done on
a single machine. Given that "older" hardware is extremely cheap and might
be able to do some parts of this work very well, I believe this would
offer an interesting setup to work with. In fact, the system may be made
"smart" so that different paths on the jack graph are treated "in
parallel": this way, we might even be able to send and receive the data
through the network within a single jack "cycle".
As Steve Harris also pointed out, a system like this can only output data
from a single machine, since everything needs to be run in sync with the
soundcard; compensating for the innacuracies doesn't seem to be adequate
on this scenario, which is geared IMHO to a recording studio, where plugin
processing power AND absolute audio quality are mandatory. However, maybe
adding the possibility of multiple soundcards on different machines with
drift compensation is an interesting idea and useful in other setups.
If the proof-of-concept implementation goes reasonably well, I intend to
pursue this further and make this the subject of my masters thesis.
As for the patent of Magic, I didn't read the specs, but from the
description of what Magic is, I guess this goes like:
Tech: "Hey, what if we use a network like ethernet to send data around
between digital equipment?"
Boss: "Great idea! Let's patent it."
Needless to say, that's ridiculous. The only "original" idea here is that
the data is audio, which is as original an idea as transposing the art of
fugue to a brass quartet.
See ya,
Nelson
This archive was generated by hypermail 2b28 : Sat Jun 15 2002 - 10:54:10 EEST