netdev - Re: [alsa-devel] [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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <07283da9-f6d1-c3b1-7989-a6fce7ca0ee6@linux.intel.com>
Date:	Tue, 21 Jun 2016 10:45:18 -0700
From:	Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:	Richard Cochran <richardcochran@...il.com>
Cc:	alsa-devel@...a-project.org, netdev@...r.kernel.org,
	Henrik Austad <henrik@...tad.us>, linux-kernel@...r.kernel.org,
	Takashi Sakamoto <o-takashi@...amocchi.jp>,
	Arnd Bergmann <arnd@...aro.org>, linux-media@...r.kernel.org
Subject: Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

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'

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