[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160614121844.54a125a5@lxorguk.ukuu.org.uk>
Date: Tue, 14 Jun 2016 12:18:44 +0100
From: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To: Richard Cochran <richardcochran@...il.com>
Cc: Henrik Austad <henrik@...tad.us>, linux-kernel@...r.kernel.org,
linux-media@...r.kernel.org, alsa-devel@...r.kernel.org,
netdev@...r.kernel.org, henrk@...tad.us,
Arnd Bergmann <arnd@...aro.org>
Subject: Re: [very-RFC 0/8] TSN driver for the kernel
On Mon, 13 Jun 2016 21:51:36 +0200
Richard Cochran <richardcochran@...il.com> wrote:
> On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote:
> > 3. ALSA support for tunable AD/DA clocks. The rate of the Listener's
> > DA clock must match that of the Talker and the other Listeners.
> > Either you adjust it in HW using a VCO or similar, or you do
> > adaptive sample rate conversion in the application. (And that is
> > another reason for *not* having a shared kernel buffer.) For the
> > Talker, either you adjust the AD clock to match the PTP time, or
> > you measure the frequency offset.
>
> Actually, we already have support for tunable clock-like HW elements,
> namely the dynamic posix clock API. It is trivial to write a driver
> for VCO or the like. I am just not too familiar with the latest high
> end audio devices.
Why high end ? Even the most basic USB audio is frame based and
isosynchronous to the USB clock. It also reports back the delay
properties.
Alan
Powered by blists - more mailing lists