On Thursday 19 August 2004 12:35 am, Lee Revell wrote:
On Wed, 2004-08-18 at 21:27, John Check wrote:
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*
BZZT, wrong. This kind of thinking
On Aug 18, 2004, at 2:15 AM, Paul Davis wrote:
and in fact, jlc and i have done some tentative experiments with
*live network audio* using jackd and ices w/jack support using only
our DSL connectivity. the model that ices uses is more or less
perfect, i think. just a client with some ports that
Quoting Steve Harris [EMAIL PROTECTED]:
I disagree, its not the wrong model - the master node (with the audio i/o)
run a normal jack driver, and all the slave nodes run a network jack
driver that read/writes from the network.
Yes, I believe this is the way to do it. Has anybody played with
Quoting Dave Robillard [EMAIL PROTECTED]:
I still say networked audio belongs in jack, not a plugin.
It belongs in both:
- If you want to use the network to increase your total processing
power, you probably just want to offload some plugins to a remote
machine. Sure, you may run
I'd really suggest considering the pros of integrating IETF tools
(SIP, RTSP, RTP) into this scheme. You could use still use jack
as your application later, but instead of engineering your own
transport layers for session management (SIP, RTSP) and media
(RTP), you'd use IETF protocols -- just
Quoting Paul Davis [EMAIL PROTECTED]:
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
On Tuesday 17 August 2004 08:19 pm, Dave Robillard wrote:
On Tue, 2004-08-17 at 16:50, John Check wrote:
On Tuesday 17 August 2004 12:53 pm, Ralf Beck wrote:
Am Dienstag, 17. August 2004 01:47 schrieb Lee Revell:
On Mon, 2004-08-16 at 19:24, Dan Hollis wrote:
On Mon, 16 Aug 2004,
On Aug 18, 2004, at 12:38 PM,
[EMAIL PROTECTED] wrote:
-- There are tools for synchronization (RTCP mappings of NTP
and RTP timestamps), tools for security (SRTP), tools for
all sorts of things someone might need to do someday.
this does seem very useful. there's no way to transport
Am Mittwoch, 18. August 2004 19:36 schrieb Nelson Posse Lago:
Quoting Paul Davis [EMAIL PROTECTED]:
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
On Wed, Aug 18, 2004 at 02:36:10 -0300, Nelson Posse Lago wrote:
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
Steve Harris [EMAIL PROTECTED] writes:
On Wed, Aug 18, 2004 at 02:36:10 -0300, Nelson Posse Lago wrote:
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
On Wed, 2004-08-18 at 21:27, John Check wrote:
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*
BZZT, wrong. This kind of thinking leads to having to upgrade every few
years just to have
On Monday 16 August 2004 08:11 pm, Dan Hollis wrote:
On Mon, 16 Aug 2004, Lee Revell wrote:
Don't need to. The email, now archived all around the world, is proof
of prior art.
Theyll just make a tweak here, a tweak there (some technical detail
overlooked in the email, but obviously
Thanks John,
The mouse problem is caused by the kernel missing usbmouse, as I didn't
have one to test it when I built the kernel (got one now so the next
build should be ok).
It's great news that it's working with Nvidia cards, this is a mixture
of X.org's X11R6.7.0 and Jennifer Dillon's
On Tuesday 17 August 2004 03:48 am, Phil Kerr wrote:
Thanks John,
The mouse problem is caused by the kernel missing usbmouse, as I didn't
have one to test it when I built the kernel (got one now so the next
build should be ok).
It's great news that it's working with Nvidia cards, this is a
Am Dienstag, 17. August 2004 01:47 schrieb Lee Revell:
On Mon, 2004-08-16 at 19:24, Dan Hollis wrote:
On Mon, 16 Aug 2004, John Check wrote:
That was exactly what I was thinking when the penny dropped for me.
Originally I was thinking of offload the softsynths, but FX are
expensive
On Tuesday 17 August 2004 12:53 pm, Ralf Beck wrote:
Am Dienstag, 17. August 2004 01:47 schrieb Lee Revell:
On Mon, 2004-08-16 at 19:24, Dan Hollis wrote:
On Mon, 16 Aug 2004, John Check wrote:
That was exactly what I was thinking when the penny dropped for me.
Originally I was
On Tuesday 17 August 2004 04:00 pm, Dave Robillard wrote:
On Tue, 2004-08-17 at 12:53, Ralf Beck wrote:
Am Dienstag, 17. August 2004 01:47 schrieb Lee Revell:
On Mon, 2004-08-16 at 19:24, Dan Hollis wrote:
On Mon, 16 Aug 2004, John Check wrote:
That was exactly what I was thinking
On Tue, Aug 17, 2004 at 05:59:15 -0400, Paul Davis wrote:
I'm not that familiar with jack internals, but writing a new jack driver
(like the firewire one, and oss one) would be a much, much better idea
than writing some alsa-over-network monstrosity for too many reasons to
list.
Err..
On Tuesday 17 August 2004 05:59 pm, Paul Davis wrote:
I'm not that familiar with jack internals, but writing a new jack driver
(like the firewire one, and oss one) would be a much, much better idea
than writing some alsa-over-network monstrosity for too many reasons to
list.
Err.. yeah
On Sunday 15 August 2004 05:36 am, Dan Hollis wrote:
On Sun, 15 Aug 2004, Steve Harris wrote:
But if youre going to do that, why use ethernet? You'd need dedicated
NICs and switches, so you may as well use firewire, which has dedicated
realtime channels, more bandwidth and doesnt require
On Sunday 15 August 2004 04:36 am, Steve Harris wrote:
On Sat, Aug 14, 2004 at 11:39:48 -0400, John Check wrote:
I don't think raw ethernet will buy us anything over using UDP. These
few usecs less simply won't matter.
(but with ethernet you would have the disadvantage that you loose
On Sunday 15 August 2004 12:21 pm, you wrote:
Quoting John Check [EMAIL PROTECTED]:
Google Nelson Posse Lago. He stopped posting to this list about 02.. I
was wondering if he got hit by a bus or something, but apparently not.
I'm alive
And the world shines for me today... (ELO)
Sorry, I
On Sunday 15 August 2004 05:48 am, [EMAIL PROTECTED] wrote:
The current top Ethernet standard specifies max transmission speed of
10GBit/sec - 1394b is 800MBit/sec.
You can also run Ethernet over Firewire. IIRC the max. number of
devices on a 1394 chain is 63 making Ethernet more suitable
Hi Juan,
Can you send me a rundown on your setup (card type, ifconfig, switch
type).
I've not seen this problem with my setup and I know that others have run
large sessions between machines. It could be a combination of driver
and app interaction or it could be the switch. Do you have a
On Aug 16, 2004, at 12:58 AM,
[EMAIL PROTECTED] wrote:
Juan Linietsky [EMAIL PROTECTED] writes:
I tried this myself, on a 100mbit ethernet switch.. while for single
instruments it seems okay, and latency is fine, playing full complex
midi
pieces in realtime had a lot of jittering...
Small
On Sat, 2004-08-14 at 16:07, Benno Senoner wrote:
The onlyproblem I envision if you want to synchronize multiple audio
cards over the network.
I think jack-over-eth would be most useful for using seperate machines
to take off the DSP load and send the audio back to the master machine
which
On Mon, Aug 16, 2004 at 03:07:45 -0400, Dave Robillard wrote:
On Sat, 2004-08-14 at 16:07, Benno Senoner wrote:
The onlyproblem I envision if you want to synchronize multiple audio
cards over the network.
I think jack-over-eth would be most useful for using seperate machines
to take off
On Monday 16 August 2004 03:07 pm, Dave Robillard wrote:
On Sat, 2004-08-14 at 16:07, Benno Senoner wrote:
The onlyproblem I envision if you want to synchronize multiple audio
cards over the network.
I think jack-over-eth would be most useful for using seperate machines
to take off the DSP
On Mon, 16 Aug 2004, John Check wrote:
That was exactly what I was thinking when the penny dropped for me.
Originally I was thinking of offload the softsynths, but FX are expensive too.
The ideal is to make a total system, but make it modular, and give it the
ability to connect with
On Monday 16 August 2004 04:38 pm, Steve Harris wrote:
On Mon, Aug 16, 2004 at 03:07:45 -0400, Dave Robillard wrote:
On Sat, 2004-08-14 at 16:07, Benno Senoner wrote:
The onlyproblem I envision if you want to synchronize multiple audio
cards over the network.
I think jack-over-eth
On Monday 16 August 2004 07:24 pm, Dan Hollis wrote:
On Mon, 16 Aug 2004, John Check wrote:
That was exactly what I was thinking when the penny dropped for me.
Originally I was thinking of offload the softsynths, but FX are expensive
too. The ideal is to make a total system, but make it
On Mon, 16 Aug 2004, Lee Revell wrote:
Don't need to. The email, now archived all around the world, is proof
of prior art.
Theyll just make a tweak here, a tweak there (some technical detail
overlooked in the email, but obviously critical to its implementation).
Look at what happened with
On Sat, Aug 14, 2004 at 11:39:48 -0400, John Check wrote:
I don't think raw ethernet will buy us anything over using UDP. These
few usecs less simply won't matter.
(but with ethernet you would have the disadvantage that you loose
routability)
It probably wouldn't be the best idea to
On Sun, 15 Aug 2004, Steve Harris wrote:
But if youre going to do that, why use ethernet? You'd need dedicated NICs
and switches, so you may as well use firewire, which has dedicated
realtime channels, more bandwidth and doesnt require switching. 400meg
Firewire cards are down to about 7 or 8
The current top Ethernet standard specifies max transmission speed of
10GBit/sec - 1394b is 800MBit/sec.
You can also run Ethernet over Firewire. IIRC the max. number of
devices on a 1394 chain is 63 making Ethernet more suitable for large
clusters of interconnected MIDI workstations.
But
Steve Harris wrote:
No, the roundtrip latency is *at least* 100usecs (or whatever), the hardware
will keep re-transmitting until the packets get through.
Even if it is 100usec it's still a negligible amount of time.
Keep in mind serial MIDI is relatibely slow, press a 7 key chord and the
7th
Steve Harris wrote:
Any good suggestion how to best implement it ?
You can't just duplicate or drop samples, it will sound terrible. You need
to do some resampling. For clusters this shouldn't be an issue, just
make one device be the i/o machine and sync everything else off that.
Of
On Sun, Aug 15, 2004 at 01:58:49PM +0200, Benno Senoner wrote:
If you absolutly have to have multiple machines doing i/o then you will
need some complicated resampling stuff. Fons has been working on it, to
allow soft-sync between 2 jack systems, but I've not tried it yet.
Between a JACK
Quoting John Check [EMAIL PROTECTED]:
Google Nelson Posse Lago. He stopped posting to this list about 02.. I was
wondering if he got hit by a bus or something, but apparently not.
I'm alive
And the world shines for me today... (ELO)
Sorry, I haven't been able to keep up with the list, much
On Sun, Aug 15, 2004 at 03:27:11PM +0200, Fons Adriaensen wrote:
For example instead of resampling 1 samples to 10001, you could
copy 9000 samples and then resample 1000 to 1001. This allows the
resampling code to handle at least 10x more channels for the same,
CPU load.
It will
Paul Winkler [EMAIL PROTECTED] writes:
Another interesting comparison is modular digital multitracks
such as ADAT and DA-88. Anybody know how sync works on those
beasties?
I think ADAT sends a wordclock-like pulse over the optical link. One
machine is master. All the others slave their
It will introduce a bit of 'vibrato' on your signal, in this case
with an amplitude of 1/59 of a semitone, which is probably harmless.
I think it should be. Remember that people successfully run
multiple analog multitrack machines in sync by controlling the
motor of one with some kind of
On Sun, Aug 15, 2004 at 12:53:56PM -0500, Jack O'Quin wrote:
Paul Winkler [EMAIL PROTECTED] writes:
Another interesting comparison is modular digital multitracks
such as ADAT and DA-88. Anybody know how sync works on those
beasties?
I think ADAT sends a wordclock-like pulse over the
On Sunday 15 August 2004 06:48, [EMAIL PROTECTED] wrote:
The current top Ethernet standard specifies max transmission speed of
10GBit/sec - 1394b is 800MBit/sec.
You can also run Ethernet over Firewire. IIRC the max. number of
devices on a 1394 chain is 63 making Ethernet more suitable for
On Saturday 14 August 2004 04:07 pm, Benno Senoner wrote:
Steve Harris wrote:
On Thu, Aug 12, 2004 at 07:32:02 -0400, Lee Revell wrote:
On Thu, 2004-08-12 at 19:21, Jody McIntyre wrote:
On Thu, Aug 12, 2004 at 07:11:44PM -0400, Dave Robillard wrote:
Well, once Jack has MIDI, all we need is a
On Saturday 14 August 2004 08:27 pm, Martijn Sipkema wrote:
From: Steve Harris [EMAIL PROTECTED]
On Sat, Aug 14, 2004 at 10:07:06PM +0200, Benno Senoner wrote:
UDP also has unbounded transit time. In practice its OK if you dont
want low latencies (just use RTP), but for low latency you
47 matches
Mail list logo
