netdev - Re: [very-RFC 0/8] TSN driver for the kernel

lists.openwall.net		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 linux-hardening linux-cve-announce 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]

Message-ID: <20160620080509.GA8011@sisyphus.home.austad.us>
Date:	Mon, 20 Jun 2016 10:05:09 +0200
From:	Henrik Austad <henrik@...tad.us>
To:	Richard Cochran <richardcochran@...il.com>
Cc:	Takashi Sakamoto <o-takashi@...amocchi.jp>,
	alsa-devel@...a-project.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, Arnd Bergmann <arnd@...aro.org>,
	linux-media@...r.kernel.org
Subject: Re: [very-RFC 0/8] TSN driver for the kernel

On Sun, Jun 19, 2016 at 11:46:29AM +0200, Richard Cochran wrote:
> 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
> resampling).

Don't get me wrong, having an adjustable clock for the sampling is 
essential -but it si not -required-.

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

No, that you cannot do that, that would not be pretty :)

> 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...

Last first; AFAIK, there is no way for the Talker to tell a Listener the 
phase offset/freq ratio other than how each end-station/bridge in the 
gPTP-domain calculates this on psync_update event messages. I could be 
wrong though, and different encoding formats can probably convey such 
information. I have not seen any such mechanisms in the underlying 1722 
format though.

So a Talker should send a stream sampled as if the gPTP time drove the 
AD/DA sample frequency directly. Whether the local sampling is driven by 
gPTP or resampled to match gPTP-time prior to transmit is left as an 
implementation detail for the end-station.

Did all that make sense?

Thanks!
-- 
Henrik Austad

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)