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

[John Lazzaro]

On Aug 18, 2004, at 2:15 AM, Paul Davis wrote:
> 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.

I'd really suggest considering the pros of integrating IETF tools
(SIP, RTSP, RTP) into this scheme.  You could use still use jack
as your application later, but instead of engineering your own
transport layers for session management (SIP, RTSP) and media
(RTP), you'd use IETF protocols -- just like you use TCP instead of
re-inventing it for each app that needs a reliable bytestream.

We're seeing the IETF stack used this way more and more in the
commercial world -- the wireless audio servers (Apple Airport
Express, etc) use RTSP and RTP.

Good reasons to do this:

   -- You may think you're trying to solve a small well-defined problem,
       but if Jack is a success, people are going to extend it to work in
       all sorts of domains.  The IETF toolset has been stretched in lots
       of ways by now -- interactive and content-streaming, unicast and
       multicast, LAN and WAN, lossy and lossless networks, etc -- and
       its known to adapt well.  Traditional go-it-alone companies, like 
Apple,
       use it all over the place -- iChat AV and Quicktime both use RTP,
       iChat AV uses SIP, Quicktime uses RTSP.

   -- Modern live-on-stage applications use video, and RTP has a
       collection of video codecs ready to go.  Ditto for whatever other
       sort of uncompressed or compressed media flow you need.

   -- There are tools for synchronization (RTCP mappings of NTP
       and RTP timestamps), tools for security (SRTP), tools for
       all sorts of things someone might need to do someday.

   -- The IPR situation is relatively transparent -- you can go to the 
IETF
       website and look at IPR filings people have made on each
       protocol, and at least see the non-submarine IPR of the people
       who actually developed the protocols -- you can't be a WG member
       and keep submarine patents away from the IETF.

   -- Most of the smart people who work on media networking in all of
       its forms do not subscribe to LAD.  The easiest way to tap into 
their
       knowledge is to use their protocols. And likewise, the smart 
people
       here can take their results and turn them into standards-track 
IETF
       working group items, and help make all media apps work better.

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---