lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 19 Jun 2016 11:46:29 +0200
From:	Richard Cochran <>
To:	Henrik Austad <>
Cc:	Takashi Sakamoto <>,,,, Arnd Bergmann <>,
Subject: Re: [very-RFC 0/8] TSN driver for the kernel

On Sun, Jun 19, 2016 at 12:45:50AM +0200, Henrik Austad wrote:
> edit: this turned out to be a somewhat lengthy answer. I have tried to 
> shorten it down somewhere. it is getting late and I'm getting increasingly 
> incoherent (Richard probably knows what I'm talking about ;) so I'll stop 
> for now.

Thanks for your responses, Henrik.  I think your explanations are on spot.

> note that an adjustable sample-clock is not a *requirement* but in general 
> you'd want to avoid resampling in software.

Yes, but..

Adjusting the local clock rate to match the AVB network rate is
essential.  You must be able to *continuously* adjust the rate in
order to compensate drift.  Again, there are exactly two ways to do
it, namely in hardware (think VCO) or in software (dynamic

What you cannot do is simply buffer the AV data and play it out
blindly at the local clock rate.

Regarding the media clock, if I understand correctly, there the talker
has two possibilities.  Either the talker samples the stream at the
gPTP rate, or the talker must tell the listeners the relationship
(phase offset and frequency ratio) between the media clock and the
gPTP time.  Please correct me if I got the wrong impression...


Powered by blists - more mailing lists