[hpsdr] Ozy/Mercury Protocol

[Kim Hawtin]

Andrea Montefusco wrote:
> ***** High Performance Software Defined Radio Discussion List *****
> 
> Alberto I2PHD wrote:
>> ***** High Performance Software Defined Radio Discussion List *****
> 
> [...]
> Many thanks for detailed explanation of WinRad code, Alberto.
> 
>  > Of course, all the above is true if the demodulated data are sent again
>  > to the FPGA, which uses the same
>  > exact clock for input and for output.
>> If instead the output goes to a sound card, which has its own sampling 
>> clock, things become a little more
>> complicated. A difference in the clocks is _unavoidable_ and must be 
>> taken into account. Some do drop
>> samples or insert empty samples, but this causes clicks or bops.
>> This is how I solved the problem in Winrad.
> 
> I was seeking this info, because I believe the John (and my) problem in 
> Linux
> arises at this point.
> The problem now becomes: how do it resample the output stream (to
> take in account the audio card clock skew) ?
> 
> Indeed, searching better in jack wiki, our case is very similar to
> using 2 or more soundcards not synced via wordclock (common clock).
> See:
> http://trac.jackaudio.org/wiki/WalkThrough/User/AlsaInOut
> 
> A crude solution could be to configure jack to ignore audio card (via 
> the dummy driver),
> connect DttSP and John's ghpsdr module to the jack patchbay.
> Next start
> 
> alsa_out -d hw:1 -f 30000
> 
> and patch it to the DttSP output via jack patchbay.
> 
> Or we can grab the sophisticated Alberto's code, creating a utility 
> program to be used
> instead of alsa_out.

jackd is a service bus, ie, you have two processes, one reading and another writing on a particular channel.

jackd just handles a number of streams, each with their own bandwidth and timing information.
my experience with jackd is that you can tie two applications together on a single or pair of streams
and send triggers on that service bus. triggers like, start recording, stop recording etc.

so with the timing data, as Alberto suggests, as long as the average time to service the I/Os on the data
packets are met it should be seamless.

i would avoid sound cards as much as possible for you input channel, they only introduce
sampling errors and noise. for the output, it doesn't matter so much. on the input, the issues
are not so much clock drift, but interrupt servicing, buffer overflow and DMA transfer issues
especially under Windows, in my experience.

i suppose the main question is, how much data are you throwing at the interfaces?
more than half the typical bandwidth of they device?
even if we are talking about "48/96/192ksps" (i assume this means kilo bits per second?)
we can look at what USB1 provides, 12 MegaBits per second.

even with packet acknowledgment and other protocol overhead, USB1 or USB2 should have more than
enough bandwidth to handle at least 30 concurrent streams.

while i have not looked at the code for jackd, its a producer->bus->filter->bus->consumer arrangement.
so a simple client for the linux producer side could be written to talk to the USB device and transfer
the data to jackd on say channel 1 and then have a filter plugin listen on channel 1 and write the data
off to the intended application on channel 2, etc... jackd should keep all the timing consistent and
your application can listen on channel 2.

while most modern and sane Linux distributions ship jackd, pulse audio is another possibility.
i was at talk about it at LinuxConf in 2008 with the chief developer of pulse audio discussing the
many issues with its use and improvements on the way. especially focusing on being real time oriented.
that said, in my experience its not as reliable as jackd, but the key aim of pulse audio is to
low latency. i don't see that as being a big deal in this application. it may be worth looking at
if very low latency is required, but my experience is its more fragile and still in heavy development.

which brings me to ALSA. ALSA is fine for applications sending audio out, or simple recording. however
its not really suitable for multi track play through or low latency work. perhaps best used as a
method for playing out your final jack stream out to your sound card.

regards,

Kim - VK5FNET
-- 
http://vk5fnet.blogspot.com/

 1250992847.0