On Mon, Mar 3, 2008 at 1:53 PM, Kevin Cosgrove <kevinc(a)cosgroves.us> wrote:
On 3 March 2008 at 10:54, "Mark Knecht" <markknecht(a)gmail.com> wrote:
I think this sounds like a better solution. I
would personally look
for a way to treat the audio information as data, calculate the the
expected data from each card and then do a comparison of input and
output data mathematically.
A cross-correlation between the captured data on a channel in
one unit versus a channel in the other unit would be the right
thing here. A value of 1 would be perfect. In practice you
won't achieve that even between channels in the same unit. I
suppose if the match across the two units were as good as the
match across channels within one unit, then one could really
consider the two Delta 1010s as one larger unit.
Yep, that's one way to do it.
In all likelihood, there are going to be small
phase shift differences
between the cards.
I don't know if I'd really expect drift. I'd expect jitter more than
drift.
The inputs won't be perfectly in sync even if
they
are coming from the same sine wave generator. I would probably doing
something like a standard deviation comparison
Std dev of what? Frequency? Period?
I think cross correlation may be easier.
I was thinking of the data itself. If you are inputting a sine wave
you have an equation so you could build a perfect data set assuming
you really know the frequency. More practical would be to use the
master's receive data and then look at how much the slave is deviating
from that. I like the cross correlation idea better as it really
doesn't make any assumptions about what the data is but only that the
two should be identical.
between the input and
two outputs.
How would you measure the input? It would have to be digitized, or
one would have to trust it's frequency and spectral purity. Chances
are that it will drift and have jitter too. To do a really good job
at a test like this one would need a very good generator, or a test
setup like those offered by Audio Precision <http://ap.com/>.
I agree.
If the data looks identical, within some some
deviation
amount, then most likely everything is working OK. On the other hand
if there is a single byte getting dropped or added once in awhile then
it will show up doing this sort of analysis very quickly.
Before going to all the trouble, one might look up the tolerance
of crystal frequencies for the kind of crystal used in the Delta
1010. Using the possible frequency mismatch one could calculate
how long it would take for the data to get out of alignment by
one sample (either at 44.1kHz, 48kHz, or 96kHz). One could
suspect that a PLL or DLL should force the frequencies to match
at least 10X better than they would without a sync circuit. I'm
guessing that a 1000X improvement is unrealizable.
Are these two cards using the same clock? I'm assuming that both cards
have the clocks physically linked as per Timo's paper on the subject.
If they aren't all bets are off as the two crystals will NEVER give
exactly the same sample rate.
If you don't want to do it in C or some
programming language then you
can likely do it in Open Office or Excel.
Or Gnumeric, or octave, or Maxima, or any of the other Open
Source math programs.
Anyway, it seems that the test already done is a pretty good
indicator that the sync between the units is functional. Now
it's just a question of how good the design is, which is what's
left to measure. If it were me, and I also own two 1010s, I'd
test the system by recording some music and seeing how good it
sounded. Up to this point, my gear has never been the limiting
factor; it's always been the musicians that limit the ultimate
quality.
Unfortunately, my system is just slightly too old in terms of
JACK and kernel to synchronize my two units without patching and
upgrading according to:
http://www.sound-man.co.uk/linuxaudio/ice1712multi.html
I'll be upgrading as soon as I get through a few recording
projects that I'm working on.
G'luck....
--
Kevin
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user