[hpsdr] What about Jack?

[Frank Brickle]

Bob --

I assume you're talking about platforms other than Windows here.

On Tue, Jan 27, 2009 at 7:04 AM, Bob Campbell <joan-bob at bigpond.net.au>wrote:


> I see on the
> web site that 0.116 has been released.  Now my question to the net is
> what will be the version of choice in the near future?


Jack 0.116, as far as DttSP is concerned.


> If so will jack still sit in all the signal paths
> currently in use, ie in front and back of Dttsp and in the audio in and
> out and control streams?


Yes. It's not going away.


>  Maybe only some of the above?


There is *no* alternative in sight, when it comes to handling a full range
of locally-connected devices in full duplex (PCI, USB, FireWire).

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.

Transport among distributed clients, sources, and sinks is simply not part
of the problem set that jack purports to solve.


> There seem to be some questions raised over the viability of jack when
> using two synchronous Jack, and Ozy/Penny/Merc systems are connected.  I
> think John M has some concerns here.  Now currently I am trying to set
> up some test platforms to check this out in the practical world, but
> what do our more academic friends think of this problem or "no worries
> mate" situation.


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.

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.

My own opinion is that there are three choices:
(1) Live with netjack;
(2) Distribute downsampled baseband (pre-mod or post-demod) data using RTP;
(3) Wait for a standard like VITA-49 to become available in full reference
implementations.

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.

73
Frank
AB2KT


-- 
Understanding a problem is knowing why it is hard to solve it, and why the
most straightforward approaches won't work. -- Karl Popper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20090127/29d09f58/attachment-0003.htm>