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

On Tue, Jun 21, 2016 at 10:45:18AM -0700, Pierre-Louis Bossart wrote:

On 6/20/16 5:18 AM, Richard Cochran wrote:

quoted

On Mon, Jun 20, 2016 at 01:08:27PM +0200, Pierre-Louis Bossart wrote:

quoted

The ALSA API provides support for 'audio' timestamps (playback/capture rate
defined by audio subsystem) and 'system' timestamps (typically linked to
TSC/ART) with one option to take synchronized timestamps should the hardware
support them.

Thanks for the info.  I just skimmed Documentation/sound/alsa/timestamping.txt.

That is fairly new, only since v4.1.  Are then any apps in the wild
that I can look at?  AFAICT, OpenAVB, gstreamer, etc, don't use the
new API.

The ALSA API supports a generic .get_time_info callback, its implementation
is for now limited to a regular 'DMA' or 'link' timestamp for HDaudio - the
difference being which counters are used and how close they are to the link
serializer. The synchronized part is still WIP but should come 'soon'

Interesting, would you mind CCing me in on those patches?

quoted

quoted

The intent was that the 'audio' timestamps are translated to a shared time
reference managed in userspace by gPTP, which in turn would define if
(adaptive) audio sample rate conversion is needed. There is no support at
the moment for a 'play_at' function in ALSA, only means to control a
feedback loop.

Documentation/sound/alsa/timestamping.txt says:

 If supported in hardware, the absolute link time could also be used
 to define a precise start time (patches WIP)

Two questions:

1. Where are the patches?  (If some are coming, I would appreciate
  being on CC!)

2. Can you mention specific HW that would support this?

You can experiment with the 'dma' and 'link' timestamps today on any
HDaudio-based device. Like I said the synchronized part has not been
upstreamed yet (delays + dependency on ART-to-TSC conversions that made it
in the kernel recently)

Ok, I think I see a way to hook this into timestamps from the skbuf on 
incoming frames and a somewhat messy way on outgoing. Having time coupled 
with 'avail' and 'delay' is useful, and from the looks of it, 'link'-time 
is the appropriate level to add this.

I'm working on storing the time in the tsn_link struct I use, and then read 
that from the avb_alsa-shim. Details are still a bit fuzzy though, but I 
plan to do that and then see what audio-time gives me once it is up and 
running.

Richard: is it fair to assume that if ptp4l is running and is part of a PTP 
domain, ktime_get() will return PTP-adjusted time for the system? -Or do I 
also need to run phc2sys in order to sync the system-time to PTP-time? Note 
that this is for outgoing traffic, Rx should perhaps use the timestamp 
in skb.

Hooking into ktime_get() instead of directly to the PTP-subsystem (if that 
is even possible) makes it a lot easier to debug when running this in a VM 
as it doesn't *have* to use PTP-time when I'm crashing a new kernel :)

Thanks!

-- 
Henrik Austad