On Sat, 15 Jul 2017, Bearcat Şándor wrote:
Ahh, i was misunderstanding. I was under the
impression that i could just put an
extra 2 ethernet ports into my computer, install the kernel drivers and libraries
(when they're available) and have an operational Ravenna input/output. However,
if it needs a wordclock then it obviously needs a card. I had thought that the
'wordclock' was part of the data packet.
It is not word clock. but wall clock with high accuracy so word clock can be
derived. It is possible to do an end point without by treating packets in the
same way as as buffer in an audio card where alsa does not have to be aware of
the exact clock rise or fall to deal with it. However, If you wish to send audio
from an internal audio card to any aes67 endpoint. Your computer must be able to
be provide an ntp server with good enough accuracy to provide wordclock to both
your internal audio ai and to act as a master clock on the network... or be able
to sync your internal audio card to an external ntp server. This accuracy pretty
much requires a HW ntp server. As I said the intel i210 ethernet cards at
$60-ish seems to be about the cheapest route.
Depending on how synced you want things... SRC can do a very good job and the
broadcast industry uses it a lot. The zita-njbridge does a great job of
connecting two computers together and I suspect using the zita src library as
part of an aes67 driver would make <whatever> ethernet card workable so long as
the computer was never expected to be a master clock. So an aes67 network with
only two linux computers may not be usable or at least your network would not be
wholely aes67 compliant. An endpoint with no ntp able to follow a masterclock
closely doesn't seem fully compliant to me from what I have read. So the windows
drivers downloadable from various places would have the same problem of not
being fully compliant too. Some of the MacOS hw does have an ethernet chip with
builtin ntp server.
So a driver that does what the windows driver does should be possible.
It think it should be PTP [1] instead of NTP above, the latter is not accurate
enough.
PTP can also be run in software timestamping mode, hardware timestamping will be
more accurate, though [2].
[1]