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:
signature.asc
Description: Digital signature
