13 Nov
2009
13 Nov
'09
6:33 p.m.
On Fri, Nov 13, 2009 at 10:56:44PM +0100, Arnold Krille wrote:
On Friday 13 November 2009 22:37:33
fons(a)kokkinizita.net wrote:
That remains to be seen. Jitter on the network timing would not
modify the average _frequency_ of such messages, so you still have
a frequency reference. But using it to generate a good sample clock
could be quite difficult.
Fact is that if the only link between the PC and soundcard is
the network cable then either the soundcard is free-running,
or it must use Ethernet messages as a reference somehow.
Assuming free-running, a number of such cards could still be
synced in sample rate if they have word clock in/out. But that
would not sync the sample blocks, so they would still have delay
differences of an integer number of a samples.
My option would be to construct the cards that way, and use the
timing of the network messages only to align the sample blocks,
not to generate the sample clock itself. That also means the
issue appears only in a second stage, when the target is combine
multiple cards into a single device.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
- If you want the soundcard to lock to a
reference provided by
the master (PC), all you have is the timing of Ethernet
messages. For example the PC could send a message every
millisecond.
Is this possible? Despite the fact that some operating systems don't provide
that granularity, there is the outgoing network layers involved and the
incoming layers on the receivers side. I don't think these are both with a
delay constant enough to be usable as a timing source for a-d-conversion.