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

[Henrik Austad <henrik@austad.us>]

[-- Attachment #1: Type: text/plain, Size: 3116 bytes --]

On Tue, Jun 21, 2016 at 10:45:18AM -0700, Pierre-Louis Bossart wrote:
> On 6/20/16 5:18 AM, Richard Cochran wrote:
> >On Mon, Jun 20, 2016 at 01:08:27PM +0200, Pierre-Louis Bossart wrote:
> >>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?

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]