Re: [linux-audio-dev] Audio synchronization, MIDI API

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Audio synchronization, MIDI API
From: John Check (j4strngs_AT_bitless.net)
Date: Sun Aug 15 2004 - 06:39:48 EEST


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 jack-over-ethernet driver,
> >>>>and the world is ours! :)
> >>>>
> >>>>(Network transparent low latency sample-accurate cross-platform MIDI
> >>>> and audio... mmmm...)
> >>>
> >>>I assume you're joking, but I have to ask anyway: how are we to achieve
> >>>low latencies over a medium with no bounds on transmit time? :)
> >>
> >>UDP. If you don't get the packet in time, drop it and move on.
> >
> >UDP also has unbounded transit time. In practice its OK if you dont want
> >low latencies (just use RTP), but for low latency you really need one of
> >the non-IP ethernet protocols that can be relaibly used for audio.
>
> 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 have an audio system on any kind of
accessible network anyway. Switches or even bridged ethernet would do the
trick for a cluster of audio processing hosts.
 
> 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.
>

There's security issues anyway what with all the SUID programs and wide open
capabilities.

> 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.
>

The packet (or is it frame) size limit supposedly puts some limits on thing
but, well, there's alway room for Jello.

> 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.
>

<sgt schulz>
.... I know nothing.. NOTHING....
</sgt schulz>

> 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 ?
>

"Best", I dunno, but I've seen some research and have code that's supposed to
do it, implemented as a plug in. Would that I had the resources to make a VST
plugin that could talk to it. We'd be able to drop a jack-rack box into
existing commercial systems and get some real leverage.
Nah, its a crazy idea. Nevermind.

> (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)
>

Yup.

> cheers,
> Benno
> http://www.linuxsampler.org
>

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.
Err.. It's still the weekend, me go zug zug Aluna now

> >- Steve


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun Aug 15 2004 - 06:48:41 EEST