18 Aug
2004
18 Aug
'04
3:42 p.m.
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.
i think that was really my whole point. apps just see JACK ports, but
people can experiment with whatever they want for transport: the IETF
examples you gave, UDP, Gibson Magic, or something someone cooks up
themselves. the apps don't care, the user doesn't really care either.
we already have jack.udp and the RTP tools from IRCAM, plus shoutcast
support. i would expect to see more added. the key element here is
that every new protocol can be added and used independently of the
others, and *every* jack client gets to use each new protocol as
support for it arrives.
-- 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.
this does seem very useful. there's no way to transport time between 2
jackd instances right now, and it would be wise to reuse existing
technology whenever this is added. otoh, it has to be bit more
extensive since we need music and/or smpte time rather than just
wallclock time.
--p