From: Richard Cochran <richardcochran@gmail.com>
To: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: alsa-devel@alsa-project.org, netdev@vger.kernel.org,
Henrik Austad <henrik@austad.us>,
linux-kernel@vger.kernel.org, Arnd Bergmann <arnd@linaro.org>,
alsa-devel@vger.kernel.org, linux-media@vger.kernel.org
Subject: Re: [very-RFC 0/8] TSN driver for the kernel
Date: Wed, 15 Jun 2016 10:06:02 +0200 [thread overview]
Message-ID: <20160615080602.GA13555@localhost.localdomain> (raw)
In-Reply-To: <5760C84C.40408@sakamocchi.jp>
On Wed, Jun 15, 2016 at 12:15:24PM +0900, Takashi Sakamoto wrote:
> > On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote:
> >> I have seen audio PLL/multiplier chips that will take, for example, a
> >> 10 kHz input and produce your 48 kHz media clock. With the right HW
> >> design, you can tell your PTP Hardware Clock to produce a 10000 PPS,
> >> and you will have a synchronized AVB endpoint. The software is all
> >> there already. Somebody should tell the ALSA guys about it.
>
> Just from my curiosity, could I ask you more explanation for it in ALSA
> side?
(Disclaimer: I really don't know too much about ALSA, expect that is
fairly big and complex ;)
Here is what I think ALSA should provide:
- The DA and AD clocks should appear as attributes of the HW device.
- There should be a method for measuring the DA/AD clock rate with
respect to both the system time and the PTP Hardware Clock (PHC)
time.
- There should be a method for adjusting the DA/AD clock rate if
possible. If not, then ALSA should fall back to sample rate
conversion.
- There should be a method to determine the time delay from the point
when the audio data are enqueued into ALSA until they pass through
the D/A converter. If this cannot be known precisely, then the
library should provide an estimate with an error bound.
- I think some AVB use cases will need to know the time delay from A/D
until the data are available to the local application. (Distributed
microphones? I'm not too sure about that.)
- If the DA/AD clocks are connected to other clock devices in HW,
there should be a way to find this out in SW. For example, if SW
can see the PTP-PHC-PLL-DA relationship from the above example, then
it knows how to synchronize the DA clock using the network.
[ Implementing this point involves other subsystems beyond ALSA. It
isn't really necessary for people designing AVB systems, since
they know their designs, but it would be nice to have for writing
generic applications that can deal with any kind of HW setup. ]
> In ALSA, sampling rate conversion should be in userspace, not in kernel
> land. In alsa-lib, sampling rate conversion is implemented in shared object.
> When userspace applications start playbacking/capturing, depending on PCM
> node to access, these applications load the shared object and convert PCM
> frames from buffer in userspace to mmapped DMA-buffer, then commit them.
The AVB use case places an additional requirement on the rate
conversion. You will need to adjust the frequency on the fly, as the
stream is playing. I would guess that ALSA doesn't have that option?
Thanks,
Richard
next prev parent reply other threads:[~2016-06-15 8:06 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-11 23:01 [very-RFC 0/8] TSN driver for the kernel Henrik Austad
2016-06-11 23:01 ` [very-RFC 1/8] TSN: add documentation Henrik Austad
2016-06-11 23:01 ` [very-RFC 2/8] TSN: Add the standard formerly known as AVB to the kernel Henrik Austad
2016-06-11 23:01 ` [very-RFC 3/8] Adding TSN-driver to Intel I210 controller Henrik Austad
2016-06-11 23:01 ` [very-RFC 4/8] Add TSN header for the driver Henrik Austad
2016-06-11 23:01 ` [very-RFC 5/8] Add TSN machinery to drive the traffic from a shim over the network Henrik Austad
2016-06-11 23:01 ` [very-RFC 6/8] Add TSN event-tracing Henrik Austad
2016-06-12 16:58 ` Steven Rostedt
2016-06-12 21:25 ` Henrik Austad
2016-06-13 2:22 ` Steven Rostedt
2016-06-13 7:20 ` Henrik Austad
2016-06-11 23:01 ` [very-RFC 7/8] AVB ALSA - Add ALSA shim for TSN Henrik Austad
2016-06-15 11:49 ` Richard Cochran
2016-06-15 12:13 ` Henrik Austad
2016-06-15 12:43 ` Richard Cochran
2016-06-11 23:01 ` [very-RFC 8/8] MAINTAINERS: add TSN/AVB-entries Henrik Austad
2016-06-13 11:47 ` [very-RFC 0/8] TSN driver for the kernel Richard Cochran
2016-06-13 13:00 ` Henrik Austad
2016-06-13 19:32 ` Richard Cochran
2016-06-14 9:30 ` Henrik Austad
2016-06-14 18:26 ` Richard Cochran
2016-06-14 20:38 ` Henrik Austad
2016-06-15 7:04 ` Richard Cochran
2016-06-15 7:50 ` Henrik Austad
2016-06-15 11:41 ` Richard Cochran
2016-06-15 7:11 ` Richard Cochran
2016-06-13 19:37 ` Richard Cochran
2016-06-13 13:12 ` Arnd Bergmann
2016-06-13 15:56 ` John Fastabend
2016-06-14 8:35 ` Henrik Austad
2016-06-13 19:51 ` Richard Cochran
2016-06-14 11:18 ` One Thousand Gnomes
2016-06-14 17:04 ` Richard Cochran
2016-06-15 3:15 ` Takashi Sakamoto
2016-06-15 8:06 ` Richard Cochran [this message]
2016-06-18 5:22 ` Takashi Sakamoto
2016-06-18 22:45 ` Henrik Austad
2016-06-19 9:46 ` Richard Cochran
2016-06-20 8:05 ` Henrik Austad
2016-06-20 11:08 ` [alsa-devel] " Pierre-Louis Bossart
2016-06-20 11:49 ` Henrik Austad
2016-06-20 12:18 ` Richard Cochran
2016-06-20 12:31 ` Richard Cochran
2016-06-20 15:21 ` Richard Cochran
2016-06-21 5:54 ` Takashi Iwai
2016-06-21 6:38 ` Richard Cochran
2016-06-21 6:45 ` Takashi Iwai
2016-06-21 17:18 ` Pierre-Louis Bossart
2016-06-21 17:45 ` Pierre-Louis Bossart
2016-06-21 19:40 ` Richard Cochran
2016-06-22 12:36 ` Pierre-Louis Bossart
2016-06-23 10:38 ` Henrik Austad
2016-06-23 13:28 ` Richard Cochran
2016-06-15 3:27 ` Takashi Sakamoto
-- strict thread matches above, loose matches on Subject: below --
2016-06-11 22:22 Henrik Austad
2016-06-11 22:49 ` Henrik Austad
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160615080602.GA13555@localhost.localdomain \
--to=richardcochran@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=alsa-devel@vger.kernel.org \
--cc=arnd@linaro.org \
--cc=henrik@austad.us \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=o-takashi@sakamocchi.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).