Re: [Jack-Devel] Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

On 03/01/2011 04:39 PM, Adrian Knoth wrote:
> On Tue, Mar 01, 2011 at 02:34:27PM -0500, Paul Davis wrote:
>
>>> Jacktrip is used regularly for remote concerts or jam sessions with two or
>>> more remote locations at the same time. Depending on the remoteness of the
>> not only that, but both netjack and soundjack
>> (http://www.soundjack.eu/) *have* been used across WAN's (though not
>> the Atlantic) for live distributed performances (with a "fast lockstep
>> beat" to it).
> Firstly, I don't see why adding some AVB functionality should replace
> any of those tools (netjack/soundjack). To me, these are completely
> different use cases with some overlapping cases.
I agree.
> One thing is to stream some audio at high latency of 50ms or whatsoever,
> the other thing is to derive media clocks from a global network clock on
> a LAN.
>
> For this, just to answer one comment by Torben, it doesn't actually
> matter whether the kernel or ptpd is asking for HW timestamping. (just
> to avoid the impression I was ever implying jackd, a jack client or the
> backend should do PTP itself)
>
> Anyway, I still don't see that any of these remote jam sessions require
> *synchronous* operations (as in "one clock domain"). It's multichannel
> UDP streaming with fast capture and playback on both ends, some SRC and
> that's it. From your comments, netjack seems to serve this use case
> well, and that's fine.
>
>
> I wonder what we're discussing at all? Ah, right, me asking if remote
> jam sessions do exist. Obviously. Is it common? I don't think so. Might
> change once we all have<30ms RTT home to home, and not just university
> to university. I have<2ms to a nearby (~60km) university, and I believe
> netjack could make sense in this scenario. Plenty of bandwidth, low
> latency, probably not much jitter.
AVB was done for very low jitter, clock synchronism enforcement. It 
isn't relevant to the WAN, so the netjack/soundjack solution is ... a 
sound solution :) IMHO.

Given that Jack is an enabler for the array of Audio Workstation 
projects, and my very selfish desire to have a high-end audio 
workstation solution, and my experience in network timing and audio 
design, and my dissatisfaction with the performance of most systems 
(except for jack) I believe that the AVB bandwagon must be promoted for 
what it is supposed to be. It's use in a kernel-timed way is redundant 
to all of the existing solutions. Hardware-timed special solutions is 
the real intent. Furthermore, the real magic that was the first intent 
was to make the switches in the subnet all able to get time-sensitive 
(actually mostly video) streams to have sensible stream reservation and 
packet scheduling. The scheduling algorithm is the real magic 
Audio/Video Bridging.
> Cheers
>

1299031581.15990_0.ltw:2,a <4D6DA600.1020002 at catraeus dot com>