Bob --<br><br>I assume you're talking about platforms other than Windows here.<br><br>On Tue, Jan 27, 2009 at 7:04 AM, Bob Campbell <span dir="ltr"><<a href="mailto:joan-bob@bigpond.net.au">joan-bob@bigpond.net.au</a>></span> wrote:<br>
<div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I see on the<br>
web site that 0.116 has been released.  Now my question to the net is<br>
what will be the version of choice in the near future?</blockquote><div><br>Jack 0.116, as far as DttSP is concerned.<br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

If so will jack still sit in all the signal paths<br>
currently in use, ie in front and back of Dttsp and in the audio in and<br>
out and control streams?</blockquote><div><br>Yes. It's not going away.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">  Maybe only some of the above?</blockquote>
<div><br>There is *no* alternative in sight, when it comes to handling a full range of locally-connected devices in full duplex (PCI, USB, FireWire).<br><br>The key point here is low-latency full-duplex. That issue cannot be stressed enough. Most of the idiosyncrasies in jack are a consequence of designing first and last for low-latency full-duplex, serving multiple clients on a single host.<br>
<br>Transport among distributed clients, sources, and sinks is simply not part of the problem set that jack purports to solve.<br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

There seem to be some questions raised over the viability of jack when<br>
using two synchronous Jack, and Ozy/Penny/Merc systems are connected.  I<br>
think John M has some concerns here.  Now currently I am trying to set<br>
up some test platforms to check this out in the practical world, but<br>
what do our more academic friends think of this problem or "no worries<br>
mate" situation.</blockquote><div><br>At the present time the only standard way to "synchronize" jack systems is with netjack, which compensates for variable transport latencies by resampling. That is unlikely to change anytime soon.<br>
<br>This isn't an academic issue for the developers out there killing themselves trying to produce and support production-level DAW systems on Linux and OSX.<br><br>My own opinion is that there are three choices:<br>(1) Live with netjack;<br>
(2) Distribute downsampled baseband (pre-mod or post-demod) data using RTP;<br>(3) Wait for a standard like VITA-49 to become available in full reference implementations.<br><br>We might like to believe there are better ways, but for the time being there are more important things to work on. In my opinion. It's bad enough that HPSDR is still basically Windows-centric.<br>
<br>73<br>Frank<br>AB2KT<br> <br></div></div><br>-- <br>Understanding a problem is knowing why it is hard to solve it, and why the most straightforward approaches won't work. -- Karl Popper <br>