Subject: [AVT] What a shame these guys seem to have never heard of RTP

From: Adrian Freed <[email-masked]>
Date: Fri, 14 Dec 2001 13:09:51 -0800

This thread has resurrected a good many of the now well-known design issues for low-latency. robust pro audio networking. As a catalyst of the early work that resulted in the Gibson projects discussed I would like to make a few observations:
	Fast Ethernet hardware can move the bits around reliably. We have been doing this in live audio production for many years with UDP and have experimented with RTP for streaming our SDIF data. Gig ethernet works too for this and is nearing the important  $50/node retail price point.
	Moving the bits around is no longer the main challenge. The problem is networked clock synchrony. I haven't encountered a research or commercial group that hasn't significantly underestimated the impact and difficulty of this issue. It is the prime reason that IEEE1394 hasn't taken off for pro-audio as acknowledged in technical papers from a major industry player: Yamaha. Here is a quick summary of the approaches:
	1a) out of band synchrony via a separate house clock or synch cable
	1b) RF synch, e.g, via GPS 
	2) phase lock loop clock recovery on a (non-audio) feature of packets
	3) sample rate conversion on each node use stable (crystal) clock source

1a) is currently  the only technique in widespread use. It uses a lot of extra cabling that needs a lot of care to implement correctly.
1b) is mainly used in wide area configurations where satellites can be synchronized to.
2) is used successfully with AES-3/SPDIF etc. in point to point configurations. Nobody I am aware of has managed to engineer a cheap way to do this with pro-audio jitter attenuation and low-latency numbers in complex LAN set ups. Not with USB, IEEE1394 or ethernet physical layers.
3) This is in my opinion the cheapest and easiest route since it tackles the problem with silicon and digital signal processing operations which can be integrated with the PHY chips. It has been used in chips by Creative Labs and Emu very successfully. There is a nasty PR problem though since the bits being heard at each node are not the same. Many people feel  this "violates" the benefit of digital audio, i.e. that perfect dubs can be made. This is the current focus of my work on wireless pro-audio applications.

The cable/connector reliability issue is a thorny one but viable technical solutions are known. I gave a paper reminding people of the advantages of coax and triax for these applications a few years ago. The major issues here seem to be commercial in nature, i.e. which legacy connector to preserve/promote?

Power distribution is the remaining major issue. Ohms law seems to dictate 90% of this. When you have relatively little copper over long  distances (i.e. Cat 5 cable) the only way to provide high power without thermal safety issues is a high voltage. You can't have too high a voltage or you have other safety issues. This is the same tradeoff faced in large scale power distribution in the power grid. 802.11af have worked on this at length for CAT 5 using 48v which is about as high as you can safely go. The problem is you then need to pay the price of a DC-DC convertor to efficiently operate at the ever lower "standard" integrated circuit power levels 3.3, 3.0, 2.5, 1.5.... Hopefully VOIP applications growth  will bring these prices down for everybody.

It is very exciting to see companies like Gibson confronting all these problems in a focused effort and to see their openness to feedback from outside users and developers.

-- 
Adrian Freed, Research Director, CNMAT, UC Berkeley. (510 643 9990 x 308
http://www.cnmat.berkeley.edu/~adrian

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www1.ietf.org/mailman/listinfo/avt

---

From: Chuck Harrison <[email-masked]>
Date: Fri, 14 Dec 2001 13:37:41 -0800

All,

Adrian's option (3) below is, I believe, the *only* option if
there is more than one autonomous clock in the system. All the
other methods rely on a "slave" relationship in which the clock
frequency/phase of most (i.e. all but one) transmitters and
receivers can be dynamically controlled in order to deliver an
isochronous data transfer environment. I believe there is
considerable potential for network-based clock-control 
messages to support these models, but I am not aware of any
well-developed system.

There are issues with resampling which go beyond PR. For better
or worse, industry has begun to take advantage of the AES-3
infrastructure for data transfer in the form of embedded
metadata and compressed multichannel audio (e.g. AC-3).
These functions are not supported in resampled environments.
It is important to inform pro users that resampling-based
systems are *not* "AES-3 over the internet" so that they
do not make unwarranted assumptions.

Cheers,
  Chuck Harrison
  Far Field Associates, LLC
  +1 360 863 8340 (voice)  PST = GMT-0800

Adrian Freed wrote:
[...]
>         3) sample rate conversion on each node use stable (crystal) clock source
[...]

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Sat, 15 Dec 2001 12:07:24 -0500

I'm guessing that sample-level clock synchronization is needed for
mixing operations spanning multiple streams, not, say, multi-track
recording?

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Marshall Eubanks" <[email-masked]>
Date: Sun, 16 Dec 2001 14:39:06 -0500

On Fri, 14 Dec 2001 13:09:51 -0800
 Adrian Freed <[email-masked]> wrote:
> This thread has resurrected a good many of the now
> well-known design issues for low-latency. robust pro
> audio networking. As a catalyst of the early work that
> resulted in the Gibson projects discussed I would like to
> make a few observations:
> 	Fast Ethernet hardware can move the bits around
> reliably. We have been doing this in live audio
> production for many years with UDP and have experimented
> with RTP for streaming our SDIF data. Gig ethernet works
> too for this and is nearing the important  $50/node
> retail price point.
> 	Moving the bits around is no longer the main challenge.
> The problem is networked clock synchrony. I haven't
> encountered a research or commercial group that hasn't
> significantly underestimated the impact and difficulty of
> this issue. It is the prime reason that IEEE1394 hasn't
> taken off for pro-audio as acknowledged in technical
> papers from a major industry player: Yamaha. Here is a
> quick summary of the approaches:

Some thoughts from a time keepers perspective.

1/4 sample at 48 k samples / sec is 5.2 microseconds.

It seems to me that this is primarily a syntonization not
synchronization issue. Even on my LAN, the box to box
delay is 160 microseconds, so there will be delay's  at this
level. I might also point out that sound travels about 1.5
mm in 5.2 microseconds, so not even live symphony orchestras
are synchronized at anywhere near this level.

For syntonization (i.e., removing delay jitter and drift), 
it can be done - and cheaply - with GPS. Tom Clark's
totally accurate clock kit (http://www.tapr.org/tapr/html/Ftac2.html
)
is good to about 50 nanoseconds. (You will need roof access
for this.)

Conversely, Internet time is a lot worse than this. I
do not think that RTP (or NTP) type round trip clock
syncs are going to be anywhere near this good - 
NTP on the commodity Internet is never as good as 1
millisecond absolute (48 samples), and even on a LAN
you will not do much better in my experience than
20 microseconds or so delay jitter.

> 	2) phase lock loop clock recovery on a (non-audio)

This is how RF time sync is routinely done, except that it
needs to be done in band (audio filters, etc., will cause
delays at the microsecond level for sure). For example,
put 0.1% of your total power into a tone at 22 kHz (for 48
ksample / sec professional audio). This will tell you the
delay through the entire audio path, and can be
removed later through a matched filter followed by a low
pass filter. 

Obviously, doing this is beyond RTP itself. However, maybe
RTP should allow for a syntonization feature, where packets
are sent with syntonization tones embedded. Such a feature
plus RTP clock sync and GPS clocks would enable the 
syntonization of an complete audio event spread over
several continents.

> 	3) sample rate conversion on each node use stable

Crystal clocks are never better than 10^-10, so
this would need correcting every 12 hours or so, unless I am
missing something from this proposal.

Regards
Marshall Eubanks

> 1a) is currently  the only technique in widespread use.
> It uses a lot of extra cabling that needs a lot of care
> to implement correctly.
> 2) is used successfully with AES-3/SPDIF etc. in point to
> point configurations. Nobody I am aware of has managed to
> engineer a cheap way to do this with pro-audio jitter
> attenuation and low-latency numbers in complex LAN set
> ups. Not with USB, IEEE1394 or ethernet physical layers.
> 3) This is in my opinion the cheapest and easiest route
> since it tackles the problem with silicon and digital
> signal processing operations which can be integrated with
> the PHY chips. It has been used in chips by Creative Labs
> and Emu very successfully. There is a nasty PR problem
> though since the bits being heard at each node are not
> the same. Many people feel  this "violates" the benefit
> of digital audio, i.e. that perfect dubs can be made.
> This is the current focus of my work on wireless
> pro-audio applications.
> 
> The cable/connector reliability issue is a thorny one but
> viable technical solutions are known. I gave a paper
> reminding people of the advantages of coax and triax for
> these applications a few years ago. The major issues here
> seem to be commercial in nature, i.e. which legacy
> connector to preserve/promote?
> 
> Power distribution is the remaining major issue. Ohms law
> seems to dictate 90% of this. When you have relatively
> little copper over long  distances (i.e. Cat 5 cable) the
> only way to provide high power without thermal safety
> issues is a high voltage. You can't have too high a
> voltage or you have other safety issues. This is the same
> tradeoff faced in large scale power distribution in the
> power grid. 802.11af have worked on this at length for
> CAT 5 using 48v which is about as high as you can safely
> go. The problem is you then need to pay the price of a
> DC-DC convertor to efficiently operate at the ever lower
> "standard" integrated circuit power levels 3.3, 3.0, 2.5,
> 1.5.... Hopefully VOIP applications growth  will bring
> these prices down for everybody.
> 
> 
> It is very exciting to see companies like Gibson
> confronting all these problems in a focused effort and to
> see their openness to feedback from outside users and
> developers.
> 
> 	
> --