[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9a5abd48-4da3-945d-53c9-b6d37010ab0d@linux.intel.com>
Date: Mon, 20 Jun 2016 13:08:27 +0200
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To: Henrik Austad <henrik@...tad.us>,
Takashi Sakamoto <o-takashi@...amocchi.jp>
Cc: alsa-devel@...a-project.org, netdev@...r.kernel.org,
Richard Cochran <richardcochran@...il.com>,
linux-kernel@...r.kernel.org, Arnd Bergmann <arnd@...aro.org>,
linux-media@...r.kernel.org
Subject: Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel
> Presentation time is either set by
> a) Local sound card performing capture (in which case it will be 'capture
> time')
> b) Local media application sending a stream accross the network
> (time when the sample should be played out remotely)
> c) Remote media application streaming data *to* host, in which case it will
> be local presentation time on local soundcard
>
>> This value is dominant to the number of events included in an IEC 61883-1
>> packet. If this TSN subsystem decides it, most of these items don't need
>> to be in ALSA.
>
> Not sure if I understand this correctly.
>
> TSN should have a reference to the timing-domain of each *local*
> sound-device (for local capture or playback) as well as the shared
> time-reference provided by gPTP.
>
> Unless an End-station acts as GrandMaster for the gPTP-domain, time set
> forth by gPTP is inmutable and cannot be adjusted. It follows that the
> sample-frequency of the local audio-devices must be adjusted, or the
> audio-streams to/from said devices must be resampled.
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.
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.
Powered by blists - more mailing lists