On Thu, 2004-08-12 at 18:46, Steve Harris wrote: Well, once Jack has MIDI, all we need is a jack-over-ethernet driver, and the world is ours! :) (Network transparent low latency sample-accurate cross-platform MIDI and audio... mmmm...) -DR-

On Thu, 2004-08-12 at 19:21, Jody McIntyre wrote: UDP. If you don't get the packet in time, drop it and move on. Lee

Steve Harris 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) On a 100Mbit network the round trip latency between hosts is about 100usecs so the one way latency of MIDI would be about half of that. and that's form a MIDI point of view instantaneous because over serial MIDI cable transmitting a NOTE ON event (3 bytes) takes about 1.1msec which is 20 times slower than transmitting it over an ethernet cable. About the packet loss ratio: besides from broken equipement (avoid hubs completely, use only switched networks), the packet loss ration in a LAN is pratically zero. What you must avoid is to saturate the network (eg having 2 hosts that flood the 100Mbit network with over 100Mbit) because at that point packets might get lost. But only a fool would try to use a saturated network to do professional audio/midi work and hoping to achieve low latencies and no packet loss. I tried a cheap $50 8port 100Mbit D-link switch and sent udp packets as fast as possible from one linux box to the other and measured the packet loss ratio (or on host1 you can use ping -f host2). It ran several hours and the packet loss ratio was zero. This means you can use UDP for audio/midi on a LAN without fearing compromising your audio work. Of course all elements must play nice (all machines must run on low latency kernels and low latency friendly audio cards using reasonable buffer sizes). If you follow a few simple rules audio/midi over UDP is just as reliable as a dedicated analogue cable. RTP is simply UDP with statistic gathering which could be useful in some cases but not necessarily needed. The onlyproblem I envision if you want to synchronize multiple audio cards over the network. In that case I guess sample skipping/duplication (from time to time) is the way to go. It's not hard to do but the hard thing is to keep buffers small and have the algorithm react fast to eventual drifts in sample rate. I measured the sample rate of some consumer (44100Hz) audio cards and usually it is quite stable but it varies 3-4 samples from card to card. eg card1 had 44096Hz , card2 44098Hz so assuming we use 128 frames buffers and the samplerate delta between cards is 2 samples we must insert/skip 2 samples per second in one of the cards. which means insert/skip a sample in one of each 172 buffers (of 128frames each) processed. Any good suggestion how to best implement it ? (if the audio slaves are without audio card then they will synchronize to the main node having the audio card which is easy to do) cheers, Benno http://www.linuxsampler.org

From: "Steve Harris" <S.W.Harris(a)ecs.soton.ac.uk> It is only unbounded if the network can't provide it, and if that is the case you would lose the ethernet frame, which might be difficult to handle for something like MIDI. Losing packets is not really hard real time either... --ms

Steve Harris wrote: 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 key will sound 6msec later than the 1st one. Still people are not complaining and MIDI has survived for decades as the intercommunication standard between musical instruments. But this is on a non switched ethernet network. In a non congested, switched network no backoff mechanism is needed because each ethernet port can get the full 100Mbit. This means if you don't saturate the network the UDP packet will get sent at the first. If you do pure host A -> host B communication it is impossible to saturate the network since the sender will send back to back packets and the receiver will be able to receive them all (given enough CPU speed). But we are talking of relatively sparse events. For example assume we send only note on and note off messages. (3 bytes). If you have a real serial midi interface you can do max about 1000 messages/sec and even average switches can switch 10000 ethernet frames/sec which means you can easily pipe a fully utilized serial midi stream (coming from a real MIDI device) into the 100Mbit network where you store only one MIDI message per packet and you still use 10% of the switching capacity of switch (and ethernet cards). An even greater efficiency (but it would introduce 1-2msec latency) could be achieved to gather incoming MIDI data from the real MIDI device and send them in batches perhaps along with audio data. (see the proposal I made some time ago for audio/midi over JACK). That way you get full timestamping for MIDI (you can trigger sample accurate MIDI events) and you send much less packets around thus allowing for dozen concurrent audio/midi streams on a single 100Mbit network. For example a stereo stream of 128 audio frames (32bit floats) per packet would consume 1024bytes, and since ethernet packets are 1500bytes you could use the rest for timestamped midi. When I get some time will make a few proof of concept tests and measurements to see if it is viable. (but I'm 99.9% sure it will work well becaue there is already solution of audio/midi over ethernet on Windows VST , see www.fx-max.com which seems to work well and hollywood composers love it because they have large softsamplers/HDR setups which they use for their film scoring. cheers, Benno

On Sat, Aug 14, 2004 at 11:39:48 -0400, John Check 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 euros in the UK now. The only disadvantage is that you can't (right now) cheaply run firewire over long distances, but taht will change once firewire over CAT5 cards come down in price, and this is rarely an issue with clusters anyway. 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. 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. - Steve

On Sunday 15 August 2004 05:36 am, Dan Hollis wrote: Funny you mention that because Nelson's implementation uses corba for discovery, but he says that broadcasting is sufficient.

On Sun, Aug 15, 2004 at 01:58:49PM +0200, Benno Senoner wrote: Between a JACK system and a second ALSA card, more exactly. It works with some cards, but for example not yet with USB, where the timing of the ALSA buffer ready events is very irregular. Not yet, unfinished work, waiting for more time. Depends on the program material. It works very well for speech and 'background quality' music. I don't think it will work well in the general case. But there are other possibilities. If the resample rate is close to one, eg. 1 +/- 1-e4 (most cards I guess will achieve that (?)), you can save a lot of the work by only resampling part of the time. For example instead of resampling 10000 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 introduce a bit of 'vibrato' on your signal, in this case with an amplitude of 1/59 of a semitone, which is probably harmless. An efficient implementation would be a fixed N to N-1 or N+1 resampler (that can be optimised), and kick this in 'on demand', whenever the desync approaches half a sample. The extreme case of this is of course 1 to 0 or 2, i.e. skipping or inserting samples. I think it could work even with relatively small N, say 256, if you ensure it is not used with a regular period, but a bit randomized. With is N, and a maximum relative error of 1-e4, you work only 2.56% of the time. The really hard part is estimating the resample ratio. With the current interfaces (no HW timestamps on sample buffers), a lot of filtering is required and that makes the estimation very slow. Even If ALSA would provide a timestamp on the interrupt handler (and a virtual one when USB is reformatted to 2^N buffers) that would help a lot. As a result you either have to accept a lot of extra latency to allow for the speed difference before the resample ratio is known, OR accept to wait a few seconds (probably not a real problem), OR have some a-priori knowledge of the resample ratio to 'prime' the state of the DLL. -- Fons

Paul Winkler <pw_lists(a)slinkp.com> writes: I think ADAT sends a wordclock-like pulse over the optical link. One machine is master. All the others slave their converters to that. Given sample synchronicity, doing the tape I/O is just a buffering task that each device can manage independently. Synchronizing the A/D converters is important for serious multi-track recording. Otherwise, there can be phase and jitter artifacts when mixing the tracks. I would suppose that Tascam does something similar. -- joq

the Otari Mtr90III is quoted as +/-0.04% which i think corresponds to just under 1 cent. but that really is sync. This thread is about compensating for lack of sync. cheers! -- Tim Orford

Quoting John Check <j4strngs(a)bitless.net>et>: I'm alive And the world shines for me today... (ELO) Sorry, I haven't been able to keep up with the list, much to my regret... But don't worry, I'll be back! Anyway, lowlat audio over ethernet works and the ethernet delays are negligible in practice, they are on the order of a few hundred microsseconds *with retransmits* in practice and most of the time they won't even happen. Please take a quick look at http://gsd.ime.usp.br/~lago/masters/artigo-webmidia.pdf . It is small and most of the text may be skipped (but please note the "sliding windows" stuff). As for resampling and resyncing multiple cards, that's more complicated... Quoting Benno Senoner <sbenno(a)gardena.net>et>: Definitely right. AND udp is simpler to use and allows for packets up to 64K; the resulting ethernet fragmentation, apparently, doesn't have a significant impact on performance either. This all tested with relatively low-end hardware. I didn't try, but I guess this system only works well (with lowlat) in a LAN. Again, that's right. If the net is dedicated, there should be virtually no ethernet packet loss; but even if there is, the hardware retransmits fast enough (IIRC, on the order of nanoseconds) for that to be transparent. There are four important TODO things with my code: - remove the CORBA stuff; it is a legacy from a past where I intended corba to have a much more important role, but right now it only gives us the ability to discover the nodes available, which would be much easier with multicast/broadcast. - clear up the C++ code so that it compiles with g++ 3.x. - create a simple gui for the manager (should be eeeeasy). - improve error handling (calling exit() at any error is not the best way to go ;-) See ya, Nelson ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

On Sat, 2004-08-14 at 16:07, Benno Senoner wrote: 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 would have the audio interface (like that VST powercore stuff). That way you could run a big expensive synth on another machine and just have it send it's outputs back via jack (so really you wouldn't even know it's running on another machine - just another jack port) I'm sure someone out there would have a use for syncing cards over the network, but personally I can't think of a reason it'd be useful, and it's certainly not worth the effort (if it's possible at all, which I doubt) -DR-

On Monday 16 August 2004 04:38 pm, Steve Harris wrote: Are you talking about a scenario with synced sound cards or the general streamed audio case?

On Mon, 16 Aug 2004, John Check wrote: Now watch roland or some yamaha engineer lurking on these mailing lists file a patent after reading that email, then come around and sue you later for implementing your own creation. (eg, someone here should patent it first before roland/yamaha/etc does) -Dan

On Monday 16 August 2004 07:47 pm, Lee Revell wrote: Code from 2002 also. Okay.. I said over the weekend I was going to draft some position papers so, I'm going to see if I can get that done my morning. Too much yakking and not enough hacking makes for an early grave.

On Monday 16 August 2004 08:11 pm, Dan Hollis wrote: Thats the only way to be, but I'm cynical, broke and pissed off and if I get sued, it means somebody is losing money and it won't be me.

On Tue, 2004-08-17 at 12:53, Ralf Beck 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. -DR-

wrong model. a given jackd has a single driver. a new jack client, sure. 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 happen to send audio to the rest of the world. only the user knows that, other apps just think its a regular client. jack doesn't care either, so everyone who has a different idea of how to actually connect the endpoints can do their own thing and everyone can coexist. oh, and a small correction. VST System Link has basically nothing to do with networked audio. its concerned with providing a common clock and transport control across a network. it does *not* distribute audio across the network at all. --p

Quoting Steve Harris <S.W.Harris(a)ecs.soton.ac.uk>uk>: Yes, I believe this is the way to do it. Has anybody played with this? http://www.alphalink.com.au/~rd/m/jack.udp.html Also, if this is not good for any reason, I intend to adapt my system for distributed ladspa processing to work on top of jack too: http://gsd.ime.usp.br/~lago/masters See ya, Nelson ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

On Tuesday 17 August 2004 12:53 pm, Ralf Beck wrote: Okay, it's good there is a precedent. That means we can probably take the business end of dladspa and VST'ify it. Okay nice. I'm going to set up a list etc this week, or at least start a new thread ;)

On Tuesday 17 August 2004 08:19 pm, Dave Robillard wrote: Yes well, that it's implemented as a plug in was I presume for expediency. It has a few design artifacts to it like that. The important part is the transport concept has been studied and since it's OO... And if cavemen debated killing animals for food and clothing we wouldn't be discussing opinions ;) Personally, when the concept blew into my head, "plugin" wasn't part of it. For now, it's a gateway. That application of the UNIX paradigm gives us an advantage makes it killer in the long term. Well... UNIX paradigm. Does it really matter that we use more than one data transport? I can think of some other arguments, but I have to write up a proposal for some consulting gig... I'm gonna be scarce for a day or two so hold that thought.

On Thu, 2004-08-12 at 19:21, Jody McIntyre wrote: Well, yes I was. But.. :) Keep in mind I didn't say TCP or even IP.. never underestimate what gigabit ethernet on a good switch can do. People have sent audio over ethernet with sub millisecond latencies before (google) -DR-

On Thursday 12 August 2004 07:11 pm, Dave Robillard wrote: Has anybody looked at Nelson P Lago's research and code? It's crickets and tumbleweeds anytime I've mentioned it. NIH I guess.

On Friday 13 August 2004 04:35 pm, Lee Revell wrote: Well, what I have is currently implemented as a LADSPA plug in so it already works with jack. Even though I'd like to see the theory outside the plug in framework I have other priorities at the moment. This particular thing is just one piece of a much bigger puzzle and whenever I see requests for the functionality the people asking get blown off. Truthfully? The main problem I have with the code now would get fixed faster if I flipped burgers for a week and bought a code monkey than if I read Stroustrup and neither of those tactics is an efficient use of my time. If anybody is interested in looking at the template clash I can put a bounty on it.

On Friday 13 August 2004 09:59 pm, Lee Revell wrote: Oops, I wasn't quite clear there. Been trying to bench my bass head since around 8PM. I didn't mean you specifically, I meant that has been the general reaction. I didn't pick up on the "great idea" part.