[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Fwd: [AVT] What a shame these guys seem to have never heard ofRTP]
Hi -
Here are some emails that discuss issues related to time
synchronization. The pro audio folks are the most compulsive about time
control. But, the comments are interesting. the NTP sychronization of
1 msec is good enough for most of what we do, but sometime i'm sure
we'll need to get tighter time constraints. Interesting note about the
syntonization toolkit that can give accuracy down to 50 nanosecs.
Larry
---
Professor Lawrence A. Rowe Internet: Rowe@BMRC.Berkeley.EDU
Computer Science Division - EECS Phone: 510-642-5117
University of California, Berkeley Fax: 510-642-5615
Berkeley, CA 94720-1776 URL: http://bmrc.berkeley.edu/~larry
On Fri, 14 Dec 2001 13:09:51 -0800
Adrian Freed <adrian@cnmat.berkeley.edu> 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:
> 1a) out of band synchrony via a separate house clock or
> synch cable
> 1b) RF synch, e.g, via GPS
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)
> feature of packets
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) clock source
>
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.
> 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
> avt@ietf.org
> http://www1.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
http://www1.ietf.org/mailman/listinfo/avt
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
avt@ietf.org
http://www1.ietf.org/mailman/listinfo/avt
On Fri, 14 Dec 2001 13:09:51 -0800
Adrian Freed <adrian@cnmat.berkeley.edu> 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:
> 1a) out of band synchrony via a separate house clock or
> synch cable
> 1b) RF synch, e.g, via GPS
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)
> feature of packets
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) clock source
>
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.
> 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
> avt@ietf.org
> http://www1.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
http://www1.ietf.org/mailman/listinfo/avt