2 Mar
2008
2 Mar
'08
11:23 a.m.
I was recently fortunate enough to pick up a second Delta 1010 for my
studio. I know that it's important to run these in such a way that one
card's clock is slaved to the other.
What's the best way to ensure that the cards are actually in sync?
I've recorded an hour of a metronome in Ardour with the signal split
to an input on each card and saw no drift between the tracks. I then
played them back and heard no drift even after 30 minutes, but I have
a feeling that this isn't necessarily a valid way of testing.
Thanks!
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
3 Mar
3 Mar
12:58 p.m.
On 2 March 2008 at 10:23, Joe Hartley <jh(a)brainiac.com> wrote:
What's the best way to ensure that the cards are
actually in sync?
I've recorded an hour of a metronome in Ardour with the signal split
to an input on each card and saw no drift between the tracks. I then
played them back and heard no drift even after 30 minutes, but I have
a feeling that this isn't necessarily a valid way of testing.
Your test method seems to be closest to what you'll do in actual use.
In that light it seems pretty valid to me.
Another way to test the system is to record a sine wave, maybe 1kHz
but other frequencies are good too. When you're done recording, then
run an FFT on the result and look for frequencies other than 1kHz.
If you use a large signal size, then you might end up seeing
distortion products in the frequency spectrum. Certainly you'll see
some noise that's broadly distributed. Some of that noise will be
due to clock jitter. Of that noise, some could be due to an increase
in clock jitter when using an external sync versus using the internal
clock. You could do a comparison.
Anyway, I think your system is probably sound. But, you could test
it more if it makes you happy.
Do let us know what you find out please.
Thanks....
--
Kevin
2:54 p.m.
On Mon, Mar 3, 2008 at 8:58 AM, Kevin Cosgrove <kevinc(a)cosgroves.us> wrote:
On 2 March 2008 at 10:23, Joe Hartley <jh(a)brainiac.com> wrote:
At first clush it sounded OK to me also, but after a minute I decided
that it isn't likely to find single bit failures. If there is a slow
drift between the two cards what might happen over time would be one
card (the master) would record all the data but the slave card might
skip a byte.
What's the best way to ensure that the cards
are actually in sync?
I've recorded an hour of a metronome in Ardour with the signal split
to an input on each card and saw no drift between the tracks. I then
played them back and heard no drift even after 30 minutes, but I have
a feeling that this isn't necessarily a valid way of testing.
Your test method seems to be closest to what you'll do in actual use.
In that light it seems pretty valid to me.
Another way to test the system is to record a sine
wave, maybe 1kHz
but other frequencies are good too. When you're done recording, then
run an FFT on the result and look for frequencies other than 1kHz.
If you use a large signal size, then you might end up seeing
distortion products in the frequency spectrum. Certainly you'll see
some noise that's broadly distributed. Some of that noise will be
due to clock jitter. Of that noise, some could be due to an increase
in clock jitter when using an external sync versus using the internal
clock. You could do a comparison.
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. I would not personally want to trust
either my eyes or ears in this area. Let the operation of the hardware
speak for itself.
In all likelihood, there are going to be small phase shift differences
between the cards. 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 between the input and
two outputs. 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.
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.
Hope this idea helps,
Mark
Anyway, I think your system is probably sound. But, you could test
it more if it makes you happy.
Do let us know what you find out please.
Thanks....
--
Kevin
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
3:09 p.m.
On Mon, Mar 03, 2008 at 10:54:25AM -0800, Mark Knecht 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. I would not personally want to trust
either my eyes or ears in this area. Let the operation of the hardware
speak for itself.
One way to test for exact sync is to use jdelay, with an analog
loopback from an output on card A to an input on card B.
Let it run as long as you can and verify if the delay is stable.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
11:24 p.m.
On Mon, 3 Mar 2008 19:59:42 +0100
Fons Adriaensen <fons(a)kokkinizita.net> wrote:
One way to test for exact sync is to use jdelay, with
an analog
loopback from an output on card A to an input on card B.
Let it run as long as you can and verify if the delay is stable.
Thanks for the advice and for jdelay!
I started jack up:
jackd -R -P70 -dalsa -r44100 -p128 -n2 -D -Cmulti_capture -Pmulti_playback -m -H -M
My first test sent jdelay's output through a port on card 0, which was
patched to an input iput on card 1, which jdelay used to complete the
loop.
I consistently got a delay of 453.485 frames, +/-0.001.
I then patched an output on card 0 to an input on card 0, and got
454.166 or 454.167 frames.
Finally I looped ports on card 1, and got 452.151 frames, +/-0.001.
These seem like perfectly cromulent numbers to me.
Thanks to Fons, Kevin and Mark for the enlightenment.
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
5:53 p.m.
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.
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?
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/>.
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.
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
6:58 p.m.
On Mon, Mar 3, 2008 at 1:53 PM, Kevin Cosgrove <kevinc(a)cosgroves.us> wrote:
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.
I agree.
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.
On 3 March 2008 at 10:54, "Mark Knecht" <markknecht(a)gmail.com> wrote:
Yep, that's one way to do it.
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.
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?
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/>.
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.
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
5906
days inactive
5907
days old
linux-audio-user@lists.linuxaudio.org
6 comments
4 participants
participants (4)
-
Fons Adriaensen -
Joe Hartley -
Kevin Cosgrove -
Mark Knecht