Subject: Re: [AVT] RFC3550 .... -> RTP light?

From: Ladan Gharai <[email-masked]>
Date: Tue, 7 Sep 2004 16:47:57 -0400

John:

This is certainly an interesting unicast audio application. Other than 
send timestamps, what information in a transport or control protocol, 
do you think would facilitate the synchronization of N streams?  Also 
are these audio streams being transported over a dedicated or shared 
medium?

Ladan

On Aug 18, 2004, at 6:40 PM, John Lazzaro wrote:
>
> On Aug 18, 2004, at 2:39 PM, Ladan Gharai wrote:
>>
>> An alternative to a RTP-light protocol would be a RTP profile which 
>> satisfies the features you list.
>>
>> The current version of the  "RTP Profile for TCP Friendly Rate 
>> Control" has the following properties:
>>
>>     1. is only defined for unicast flows  (no multicast)
>>     2. includes a 32 bit send timestamp and round trip time in the 
>> RTP data packet
>>
>> I'd be interested to know what other timing information media 
>> applications would be interested in exchanging between unicast 
>> sender/receivers which would be useful to add to the profile?
>
> In the general case, N unicast streams generated from a
> single sender, sent to N different receivers in the same
> room, but in different boxes.  Streams sent via Layer-2 of
> Ethernet, 801.11, Firewire, whatever.  Each of the boxes turns
> the RTP stream into an analog audio waveform put on a cable,
> the cable waveforms get mixed together in the analog domain
> and sent to speakers.
>
> The goal is single-sample synchronization between
> the analog waveforms produced by the N receivers,
> for N = 192 KHz (yes, this is the trendy sampling rate
> these days in pro-land).  Using only the Layer 2, no
> coax for word clock, etc -- the goal is to reduce cable
> madness.
>
> Obviously, it takes more than a media protocol (be it RTP
> or a new RTP-lite protocol) to make a system like meet spec --
> we've talked about the problem in the past here, and earlier
> work like the Flow Synchronization Protocol has been cited as
> an example of a "helper" protocol one needs to add.
>
> However, I do think that the features one builds into the media
> protocol makes the problem easier or harder to do -- plain
> vanilla RTP may make the problem harder than it needs to be.
>
> Finally, a workshop is actually happening in Canada this
> weekend about this very topic -- I won't be there, unfortunately,
> but maybe an AVTer will be and could report:
>
> http://www.banffcentre.ca/programs/program.aspx?id=154
>
> ---
> John Lazzaro
> http://www.cs.berkeley.edu/~lazzaro
> lazzaro [at] cs [dot] berkeley [dot] edu
> ---
>

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

---

From: "John Lazzaro" <[email-masked]>
Date: Tue, 7 Sep 2004 14:04:06 -0700

On Sep 7, 2004, at 1:47 PM, Ladan Gharai wrote:
> This is certainly an interesting unicast audio application.

Coincidentally, the AES conference abstracts for the
October SFO meeting just went out on the web, and
papers E-5 and E-4 in this session:

http://www.aes.org/events/117/papers/E.cfm

are two attempts at making this happen (from the
abstracts, it would appear that the Sony paper is
oriented to the pro-market, whereas the Microsoft
paper is oriented to the home market).

> Other than send timestamps, what information in a
> transport or control protocol, do you think would facilitate
>  the synchronization of N streams?

I haven't thought it through yet to the point of making
concrete suggestions with confidence -- so the
vagueness of my posts are on purpose :-).  It is a
problem I hope RTP can address, which is why I
post about it from time to time, on the hope someone
is inspired to go off and work on it ...

> Also are these audio streams being transported over
> a dedicated or shared medium?

People would really like shared, the idea of running two
Ethernets side by side in a studio or stage, one for
web-surfing and one for audio, begs the question:
if we're going to have two wires anyway, why not keep
using isochronous or dedicated standards for the
audio?   "One-cable" or even wireless's "no-cable"
is the big win ...

---
John Lazzaro