[hpsdr] Ozy/Mercury Protocol

[Kim Hawtin]

Kim Hawtin wrote:
> ***** High Performance Software Defined Radio Discussion List *****
> 
> 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?)

my assumption here is quite wrong. "ksps" is Kilo Samples Per Second.
where each sample is 48 bits (24 bits for I and 24 bits for Q data)
so that puts us up at the USB1 data rate by the time you add protocol
and packet headers ...

thank you Kirk KD7IRS and Glenn WB6W for the corrections.

regards,

Kim

> 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/

 1250994775.0