Re: [Jack-Devel] Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

PrevNext  Index
DateFri, 04 Mar 2011 17:17:14 -0600
From Duncan Gray <[hidden] at catraeus dot com>
To[hidden] at lists dot jackaudio dot org
In-Reply-ToChris Caudle Re: [Jack-Devel] Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2
On 03/04/2011 12:05 PM, Chris Caudle wrote:
> On Fri, March 4, 2011 3:56 am, torbenh wrote:
>> if we can cite the standard draft with some requirements for the clock,
>> which are unacceptable for clock_realtime, we would have a good argument
>> for maintaining the avb clock as a different timebase inside the kernel.
> I don't like the way IEEE draft standards are so hard to get. I can't
> really find the full standard which is currently proposed for 802.1AS (the
> synchronization standard), but here is what the working group page says:
> http://www.ieee802.org/1/pages/802.1as.html
>
> "This standard specifies the protocol and procedures used to ensure that
> the synchronization requirements are met for time sensitive applications,
> such as audio and video, across Bridged and Virtual Bridged Local Area
> Networks consisting of LAN media where the transmission delays are fixed
> and symmetrical; for example, IEEE 802.3 full duplex links. This includes
> the maintenance of synchronized time during normal operation and following
> addition, removal, or failure of network components and network
> reconfiguration. It specifies the use of IEEE 1588 specifications where
> applicable in the context of IEEE Stds 802.1D and 802.1Q. Synchronization
> to an externally provided timing signal (e.g., a recognized timing
> standard such as UTC or TAI) is not part of this standard but is not
> precluded."
>
> "This standard enables stations attached to bridged LANs to meet the
> respective jitter, wander, and time synchronization requirements for
> time-sensitive applications."
>
>
> I think the relevant point for your concern is that "(...UTC...) is not
> part of this standard but is not precluded."
>
> So if a device had capability to keep UTC and was the grandmaster, all
> well and good, but if not, the network timing still works, you just have
> no defined relationship to external time.
>
> Since it seems you would definitely want a device with hardware timing
> support to act as the grandmaster for your network, a standard PC could
> not be the grandmaster, it would have to be a time slave, and might have
> to slave to a device with no concept of UTC.
Still have it wrong.
To play in 1588 you have to have hardware assist. Period.
PrevNext  Index

1299280654.8271_0.ltw:2,a <4D7172FA.6070003 at catraeus dot com>