jump to beginning show previous Showing Logic-users Thread 97598 of 105816 show next jump to end

Forum Index | Read LUG: Policy/Rules Messages Threads Digests | Post New Message | Search!

From: Nick Batzdorf <recording@earthlink.net>
Date: Sat, 30 Sep 2006 at 2:37:27 PM
Subject: [LUG] Re: AUNetSend and AUNetReceive
Message #219290
Posted by: "Hans Hafner" hanshafner@gmx.de hans_hafner Sat Sep 30, 2006 1:21 am (PST) > Hi there, > > has anyone set up networked Macs using AUNetSend, AUNetReceive and > network MIDI to use a second Mac as a "sound-module"? > > I can get it to work no problem, but Logic becomes _extremely_ > unstable using it and crashes very very soon (> 5 minutes of working, > well... trying out) > > I was using the built-in audio interfaces on both Macs just to make > sure it's not a third-party driver problem. > > Any thoughts? > > Cheers > Hans > > Sytem: > Logic 7.2.2 > Dual G5 2.0 / 2.5 GB RAM > OS X 10.4.7 > MetricHalo MobileIO 2882 > Unitor8 Unfortunately, you may be investing good time after bad. I haven't been able to get any of the other audio-over-ethernet solutions to work either. The issue that stopped me from going farther with AUNetsend/Receive is latency - it's not workable. This is a holy grail, of course; audio-over-ethernet on Mac is just not a happening thing yet - unless something new has come out that I haven't heard about. Nick Batzdorf, editor/publisher Virtual Instruments Magazine - the world of softsynths and samplers www.Virtualinstrumentsmag.com 1-877 VImagzn (846-2496) 818/905-9101, cell 590-9101
Viewed 2190 times, 1 reply, 5 messages in thread. Reply to this message.
From: Otto Gygax <otto@gxm.com>
Date: Sat, 30 Sep 2006 at 9:39:53 PM
Subject: Re: [LUG] Re: AUNetSend and AUNetReceive
Message #219297
This is a reply to #219290.
On Sep 30, 2006, at 12:37 PM, Nick Batzdorf wrote: > > > Unfortunately, you may be investing good time after bad. I haven't > been able to get any of the other audio-over-ethernet solutions to > work either. > > The issue that stopped me from going farther with AUNetsend/Receive > is latency - it's not workable. This is a holy grail, of course; > audio-over-ethernet on Mac is just not a happening thing yet - unless > something new has come out that I haven't heard about. > > > I'm curious to know if these tests have been done over gigabit ethernet? -otto ------------------------------------------------------------------------ ------------------- Otto Gygax - Audio, Computer, Networking Engineering / Percussion otto@GxM.COM / Philomath, Oregon
Viewed 2178 times, 2 replies, 5 messages in thread. Reply to this message.
From: Hans Hafner <hanshafner@gmx.de>
Date: Sat, 30 Sep 2006 at 11:13:27 PM
Subject: Re: [LUG] Re: AUNetSend and AUNetReceive
Message #219298
This is a reply to #219297.
At 19:39 Uhr -0700 30.09.2006, Otto Gygax wrote: >I'm curious to know if these tests have been done over gigabit ethernet? In my case: yes, Powerbook and G5 were directly connected with no router or switch in between. Cheers Hans
Viewed 2176 times, 0 replies, 5 messages in thread. Reply to this message.
From: Peter Ostry <po@ostry.com>
Date: Sat, 30 Sep 2006 at 11:41:42 PM
Subject: Re: [LUG] Re: AUNetSend and AUNetReceive
Message #219299
This is a reply to #219297.
> On Sep 30, 2006, at 12:37 PM, Nick Batzdorf wrote: >> The issue that stopped me from going farther with AUNetsend/Receive >> is latency - it's not workable. This is a holy grail, of course; >> audio-over-ethernet on Mac is just not a happening thing yet - unless >> something new has come out that I haven't heard about. >> > > On 01.10.2006, at 04:39, Otto Gygax wrote: > I'm curious to know if these tests have been done over gigabit > ethernet? Maybe more an issue of the protocol than of the nominal speed. The ethernet protocol has no fixed timeslices or such. If a data block wants to travel over ethernet it sticks its head out, looks to the left and right and if it sees a free space among the other data it quickly jumps out and swims with the stream. Its following brothers and sisters get somehow organized behind the leader. If you try audio over ethernet you will see a certain amount of steady latency which does not change during one travel session. But the latency won't be the same the next time because the time when the first bits can take off differs. I am not really sure but I doubt that faster ethernet will change that situation. Maybe a much faster version but a 10 times faster net will not result in a 10 times better performance. There is still the protocol. Some time ago I played a lot with WormHole (early version) and got latencies between 1,200 and 2500 samples. Haven't tried with the new version yet which is supposed to be faster. But the real problem is that audio stream and ethernet are not synchronized. You can never tell when exactly your data leaves your machine. I guess AUNetSend/ Receive has to cook with the same water. As I tried that system I managed to record via ethernet as I had to switch to a Powerbook G4 but wanted to keep my Delta card in the old G3. That worked, I could use the audio card of another computer (!) but it was no fun. I ran Tracktion on the G3, which recorded and sent the data instantly via WormHole to the Powerbook. But I had always to maintain a parallel click track and align the recorded track manually. Cannot recommend that. Honestly, I am not sure if audio over ethernat has a future. Ethernet was never thought for that kind of stuff. If we had a kind of fast "token ring" network i.e. or a dedicated protocol for audio (I think Yamaha tried that) then yes. But with our usual networks it is currently just an interesting experiment. ___ Peter Ostry
Viewed 2190 times, 1 reply, 5 messages in thread. Reply to this message.
From: David Cake <dave@difference.com.au>
Date: Sun, 1 Oct 2006 at 7:55:01 PM
Subject: Re: [LUG] Re: AUNetSend and AUNetReceive
Message #219347
This is a reply to #219299.
>Maybe more an issue of the protocol than of the nominal speed. The >ethernet protocol has no fixed timeslices or such. If a data block >wants to travel over ethernet it sticks its head out, looks to the >left and right and if it sees a free space among the other data it >quickly jumps out and swims with the stream. Its following brothers >and sisters get somehow organized behind the leader. > >If you try audio over ethernet you will see a certain amount of >steady latency which does not change during one travel session. But >the latency won't be the same the next time because the time when the >first bits can take off differs. I am not really sure but I doubt >that faster ethernet will change that situation. Maybe a much faster >version but a 10 times faster net will not result in a 10 times >better performance. There is still the protocol. This is true enough as far as it goes, but the issues of the ethernet protocol itself can be pretty much minimised by not having any other data on the same network (and with modern networks where everything is switched, that can often be no other data on the same virtual network). If the data 'sticks its head out' and always sees no other data, the intrinsic ethernet latency is very small. Ethernet over audio should be quite doable - its just that it requires getting things right at several different levels (physical, network layout and switching, TCP/IP tuning, etc), so its hard to do well, and is nowhere near as 'plug and play' as people are used to ethernet being (especially if you want to get the latency as low as you can). >Honestly, I am not sure if audio over ethernat has a future. Ethernet >was never thought for that kind of stuff. If we had a kind of fast >"token ring" network i.e. or a dedicated protocol for audio (I think >Yamaha tried that) then yes. But with our usual networks it is >currently just an interesting experiment. Ethernet is the foundation of modern networking, and is likely to remain so for the foreseeable future, so thinking about token ring and such is just dreaming - and to be honest, I think its going to be far more practical for any use that requires a 'real' networking protocol than any alternative. Tuning ethernet right and getting an ethernet setup that has the latency as low as possible is almost certainly going to be easier in almost any situation than messing around with different protocols. Its also worth noting that its not really the case that token ring has better latency than ethernet - its just that token rings latency is far more deterministic and has an upper bound, which is a useful property in many situations, but ethernet should be as fast or faster when running in a low latency, low traffic, network. Though for small networks, where the machines are basically in the same room, firewire is probably the most practical alternative. You can run IP over firewire (its built into MacOS X), and if you want to experiment with audio over TCP/IP networking without the limitations of ethernet, that would be the obvious thing to try. I'd be interested to hear if the results are significantly better in this situation. Cheers David
Viewed 889 times, 0 replies, 5 messages in thread. Reply to this message.

Forum Index | Read LUG: Policy/Rules Messages Threads Digests | Post New Message | Search!

Forum Index | Read LUG: Policy/Rules Messages Threads Digests | Post New Message | Search!


© 1994-2008, All Rights Reserved.