[Discuss-gnuradio] Re: synchronizing sound cards in a cluster (fwd)

[Eugen Leitl]

Apologies for encouraging offtopic threads, but it's been a slow year.

---------- Forwarded message ----------
Date: Thu, 13 Mar 2003 17:07:19 -0500
From: Dave Emery <die at die.com>
To: Joseph DiVerdi <diverdi at xtrsystems.com>
Cc: discuss-gnuradio at gnu.org
Subject: Re: [Discuss-gnuradio] Re: synchronizing sound cards in a cluster

On Thu, Mar 13, 2003 at 02:10:22PM -0700, Joseph DiVerdi wrote:
> At 1:03 PM -0800 3/13/03, Matthew Kaufman wrote:
> >This isn't really the hard part. The hard part is getting multiple sound
> >cards to share the same sample clock. IF the same clocks all ran at the
> >same rate, then you could fairly easily use known inputs to synchronize
> >up the results, but the sample clocks aren't nearly close enough
> >together for that. In fact, the sample clocks in most sound cards are
> >*terrible*.
> >
> >Even synchronizing multiple sound cards inside the same PC is a
> >difficult problem for this reason.
> >
> >So, for starters, go get some sound cards that have an external clock
> >input for the sampling. (If you can find such a thing)
> >
> >Matthew
> 
> I believe Matthew is exactly correct regarding the crux of the problem and if someone were to discover a sound card with an external clock would appreciate learning about it.
> 
> In this situation it may be necessary to migrate to an analog input ADC card which very often has an external clock or trigger input.
> 
> Best regards,
> Joseph

	I've given thought (but no actual effort) to replacing the 
canned crystal timing oscillator on a soundcard with an external 
input (and a BNC or SMA connector) and feeding the thing from
a frequency synthesizer locked to GPS or a rubidium standard.

	Whether this would clean up all clock accuracy and jitter
issues I do not know (depends on the digital design of the soundcard),
but it definately does not handle the external sample trigger issue.

	It has occured to me that some soundcards may still use external
(eg not part of a big ASIC) codecs (A/D converters in this context).   
If this is the case, there is an off chance that the digital circuitry
inside the PCI or USB interface ASIC is logically asynchronous in
handling samples from the ADC rather than strictly synchronous to its
internal clock.   What this means is that ASIC provides a trigger to the
ADC and waits internally until the ADC completes its conversion and
signals done rather than simply assuming that data appears N clock ticks
after the ADC start signal and if one starts strobing in bits then one
gets the sample.

	Given a sound card with an external ADC and a PCI state machine
that waits for the ADC to say it has data rather than assuming it is
there exactly N clock ticks after a convert start signal provided by the
PCI ASIC, it might well be possible to hack the soundcard so the ADC
start signal comes from an external timing source rather than the 
sample timing synthesizer in the ASIC.   This would provide external
sample triggering, probably with a +- 1 tick of the soundcard ADC clock
jitter to allow sync up with ADC's internal clock.

	There might or might not be some constraints on such an external
trigger modification - it is quite possible the PCI state machine on the
soundcard might get royally confused if the A/D said it had data before
the ASIC issued a convert command, so it might be necessary to interlock
them with external logic, locking out the ADC start logic until after a
trigger was generated by the PCI ASIC (or locking out the ADC done
signal from the ASIC until the ASIC has called for a conversion).

	Whether such a hack is worth persuing depends on whether 
someone designs a cheap ADC for GNU radio applications.   If the
cheapest ADC is $1400 it sure is, but if a $300 board with integral
digital downconversion is developed it might not be.   I do hope the
folks developing the gnu-radio board have addressed the external sample
trigger and preferably also the external sample clock (eg supplying a
precise frequency input) issues from the git go in their design - a
board without both features is much less useful for many applications.

	Of course the big hastle is that no sound card vendor is very
likely to be willing to supply any details of the logic of his ASICs (or
even just board layout and signal names on pins) so any such hack has to
be designed the old fashioned way - by reverse engineering and
experimentation rather than study of ASIC VHDL or whatever.  One
expects that the details of the interfaces to common codecs ARE available
on their data sheets, however, so finding the signals to look at on
a logic analyzer isn't rocket science.

-- 
	Dave Emery N1PRE,  die at die.com  DIE Consulting, Weston, Mass. 
PGP fingerprint = 2047/4D7B08D1 DE 6E E1 CC 1F 1D 96 E2  5D 27 BD B0 24 88 C3 18



_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio at gnu.org
http://mail.gnu.org/mailman/listinfo/discuss-gnuradio