Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1420097 > unrolled thread

[very-RFC 0/8] TSN driver for the kernel

Back to article view | Back to linux.kernel

Contents

  [very-RFC 0/8] TSN driver for the kernel Henrik Austad <henrik@austad.us> - 2016-06-12 01:10 +0200
    [very-RFC 1/8] TSN: add documentation Henrik Austad <henrik@austad.us> - 2016-06-12 01:10 +0200
    [very-RFC 3/8] Adding TSN-driver to Intel I210 controller Henrik Austad <henrik@austad.us> - 2016-06-12 01:10 +0200
    [very-RFC 6/8] Add TSN event-tracing Henrik Austad <henrik@austad.us> - 2016-06-12 01:10 +0200
      Re: [very-RFC 6/8] Add TSN event-tracing Steven Rostedt <rostedt@goodmis.org> - 2016-06-12 19:00 +0200
        Re: [very-RFC 6/8] Add TSN event-tracing Henrik Austad <henrik@austad.us> - 2016-06-12 23:30 +0200
          Re: [very-RFC 6/8] Add TSN event-tracing Steven Rostedt <rostedt@goodmis.org> - 2016-06-13 04:30 +0200
            Re: [very-RFC 6/8] Add TSN event-tracing Henrik Austad <henrik@austad.us> - 2016-06-13 09:30 +0200
    [very-RFC 8/8] MAINTAINERS: add TSN/AVB-entries Henrik Austad <henrik@austad.us> - 2016-06-12 01:10 +0200
    Re: [very-RFC 0/8] TSN driver for the kernel Richard Cochran <richardcochran@gmail.com> - 2016-06-13 13:50 +0200
      Re: [very-RFC 0/8] TSN driver for the kernel Henrik Austad <henrik@austad.us> - 2016-06-13 15:10 +0200
        Re: [very-RFC 0/8] TSN driver for the kernel Richard Cochran <richardcochran@gmail.com> - 2016-06-13 21:40 +0200
          Re: [very-RFC 0/8] TSN driver for the kernel Henrik Austad <henrik@austad.us> - 2016-06-14 11:40 +0200
            Re: [very-RFC 0/8] TSN driver for the kernel Richard Cochran <richardcochran@gmail.com> - 2016-06-14 20:30 +0200
              Re: [very-RFC 0/8] TSN driver for the kernel Henrik Austad <henrik@austad.us> - 2016-06-14 22:40 +0200
                Re: [very-RFC 0/8] TSN driver for the kernel Richard Cochran <richardcochran@gmail.com> - 2016-06-15 09:10 +0200
                  Re: [very-RFC 0/8] TSN driver for the kernel Henrik Austad <henrik@austad.us> - 2016-06-15 10:00 +0200
                  Re: [very-RFC 0/8] TSN driver for the kernel Richard Cochran <richardcochran@gmail.com> - 2016-06-15 13:50 +0200
                Re: [very-RFC 0/8] TSN driver for the kernel Richard Cochran <richardcochran@gmail.com> - 2016-06-15 09:20 +0200
        Re: [very-RFC 0/8] TSN driver for the kernel Richard Cochran <richardcochran@gmail.com> - 2016-06-13 21:40 +0200
      Re: [very-RFC 0/8] TSN driver for the kernel Arnd Bergmann <arnd@linaro.org> - 2016-06-13 15:20 +0200
      Re: [very-RFC 0/8] TSN driver for the kernel John Fastabend <john.fastabend@gmail.com> - 2016-06-13 18:00 +0200
        Re: [very-RFC 0/8] TSN driver for the kernel Henrik Austad <henrik@austad.us> - 2016-06-14 10:40 +0200
      Re: [very-RFC 0/8] TSN driver for the kernel Richard Cochran <richardcochran@gmail.com> - 2016-06-13 22:00 +0200
        Re: [very-RFC 0/8] TSN driver for the kernel One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-06-14 13:20 +0200
          Re: [very-RFC 0/8] TSN driver for the kernel Richard Cochran <richardcochran@gmail.com> - 2016-06-14 19:10 +0200
          Re: [very-RFC 0/8] TSN driver for the kernel Takashi Sakamoto <o-takashi@sakamocchi.jp> - 2016-06-15 05:30 +0200
            Re: [very-RFC 0/8] TSN driver for the kernel Richard Cochran <richardcochran@gmail.com> - 2016-06-15 10:10 +0200
              Re: [very-RFC 0/8] TSN driver for the kernel Takashi Sakamoto <o-takashi@sakamocchi.jp> - 2016-06-18 07:30 +0200
                Re: [very-RFC 0/8] TSN driver for the kernel Henrik Austad <henrik@austad.us> - 2016-06-19 00:50 +0200
                  Re: [very-RFC 0/8] TSN driver for the kernel Richard Cochran <richardcochran@gmail.com> - 2016-06-19 11:50 +0200
                    Re: [very-RFC 0/8] TSN driver for the kernel Henrik Austad <henrik@austad.us> - 2016-06-20 11:50 +0200
                  Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> - 2016-06-20 13:20 +0200
                    Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel Henrik Austad <henrik@austad.us> - 2016-06-20 14:00 +0200
                    Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel Richard Cochran <richardcochran@gmail.com> - 2016-06-20 14:30 +0200
                      Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel Richard Cochran <richardcochran@gmail.com> - 2016-06-20 15:00 +0200
                        Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel Richard Cochran <richardcochran@gmail.com> - 2016-06-20 17:40 +0200
                          Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel Takashi Iwai <tiwai@suse.de> - 2016-06-21 08:00 +0200
                            Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel Richard Cochran <richardcochran@gmail.com> - 2016-06-21 08:40 +0200
                              Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel Takashi Iwai <tiwai@suse.de> - 2016-06-21 08:50 +0200
                        Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> - 2016-06-21 19:20 +0200
                      Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> - 2016-06-21 19:50 +0200
                        Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel Richard Cochran <richardcochran@gmail.com> - 2016-06-21 23:20 +0200
                          Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> - 2016-06-22 14:40 +0200
                        Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel Henrik Austad <henrik@austad.us> - 2016-06-23 12:40 +0200
                          Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel Richard Cochran <richardcochran@gmail.com> - 2016-06-23 15:30 +0200
          Re: [very-RFC 0/8] TSN driver for the kernel Takashi Sakamoto <o-takashi@sakamocchi.jp> - 2016-06-15 05:30 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1420823

On Monday, June 13, 2016 1:47:13 PM CEST Richard Cochran wrote:
> * Kernel Space
> 
> 1. Providing frames with a future transmit time.  For normal sockets,
>    this can be in the CMESG data.  For mmap'ed buffers, we will need a
>    new format.  (I think Arnd is working on a new layout.)
> 

After some back and forth, I think the conclusion for now was that
the timestamps in the current v3 format are sufficient until 2106
as long as we treat them as 'unsigned', so we don't need the new
format for y2038, but if we get a new format, that should definitely
use 64-bit timestamps because that is the right thing to do.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1421029

On 16-06-13 04:47 AM, Richard Cochran wrote:
> Henrik,
> 
> On Sun, Jun 12, 2016 at 01:01:28AM +0200, Henrik Austad wrote:
>> There are at least one AVB-driver (the AV-part of TSN) in the kernel
>> already,
> 
> Which driver is that?
> 
>> however this driver aims to solve a wider scope as TSN can do
>> much more than just audio. A very basic ALSA-driver is added to the end
>> that allows you to play music between 2 machines using aplay in one end
>> and arecord | aplay on the other (some fiddling required) We have plans
>> for doing the same for v4l2 eventually (but there are other fishes to
>> fry first). The same goes for a TSN_SOCK type approach as well.
> 
> Please, no new socket type for this.
>  
>> What remains
>> - tie to (g)PTP properly, currently using ktime_get() for presentation
>>   time
>> - get time from shim into TSN and vice versa
> 
> ... and a whole lot more, see below.
> 
>> - let shim create/manage buffer
> 
> (BTW, shim is a terrible name for that.)
> 
> [sigh]
> 
> People have been asking me about TSN and Linux, and we've made some
> thoughts about it.  The interest is there, and so I am glad to see
> discussion on this topic.
> 
> Having said that, your series does not even begin to address the real
> issues.  I did not review the patches too carefully (because the
> important stuff is missing), but surely configfs is the wrong
> interface for this.  In the end, we will be able to support TSN using
> the existing networking and audio interfaces, adding appropriate
> extensions.
> 
> Your patch features a buffer shared by networking and audio.  This
> isn't strictly necessary for TSN, and it may be harmful.  The
> Listeners are supposed to calculate the delay from frame reception to
> the DA conversion.  They can easily include the time needed for a user
> space program to parse the frames, copy (and combine/convert) the
> data, and re-start the audio transfer.  A flexible TSN implementation
> will leave all of the format and encoding task to the userland.  After
> all, TSN will some include more that just AV data, as you know.
> 
> Lets take a look at the big picture.  One aspect of TSN is already
> fully supported, namely the gPTP.  Using the linuxptp user stack and a
> modern kernel, you have a complete 802.1AS-2011 solution.
> 
> Here is what is missing to support audio TSN:
> 
> * User Space
> 
> 1. A proper userland stack for AVDECC, MAAP, FQTSS, and so on.  The
>    OpenAVB project does not offer much beyond simple examples.
> 
> 2. A user space audio application that puts it all together, making
>    use of the services in #1, the linuxptp gPTP service, the ALSA
>    services, and the network connections.  This program will have all
>    the knowledge about packet formats, AV encodings, and the local HW
>    capabilities.  This program cannot yet be written, as we still need
>    some kernel work in the audio and networking subsystems.
> 
> * Kernel Space
> 
> 1. Providing frames with a future transmit time.  For normal sockets,
>    this can be in the CMESG data.  For mmap'ed buffers, we will need a
>    new format.  (I think Arnd is working on a new layout.)
> 
> 2. Time based qdisc for transmitted frames.  For MACs that support
>    this (like the i210), we only have to place the frame into the
>    correct queue.  For normal HW, we want to be able to reserve a time
>    window in which non-TSN frames are blocked.  This is some work, but
>    in the end it should be a generic solution that not only works
>    "perfectly" with TSN HW but also provides best effort service using
>    any NIC.
> 

When I looked at this awhile ago I convinced myself that it could fit
fairly well into the DCB stack (DCB is also part of 802.1Q). A lot of
the traffic class to queue mappings and priories could be handled here.
It might be worth taking a look at ./net/sched/mqprio.c and ./net/dcb/.

Unfortunately I didn't get too far along but we probably don't want
another mechanism to map hw queues/tcs/etc if the existing interfaces
work or can be extended to support this.

> 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.
> 
> 4. ALSA support for time triggered playback.  The patch series
>    completely ignore the critical issue of media clock recovery.  The
>    Listener must buffer the stream in order to play it exactly at a
>    specified time.  It cannot simply send the stream ASAP to the audio
>    HW, because some other Listener might need longer.  AFAICT, there
>    is nothing in ALSA that allows you to say, sample X should be
>    played at time Y.
> 
> These are some ideas about implementing TSN.  Maybe some of it is
> wrong (especially about ALSA), but we definitely need a proper design
> to get the kernel parts right.  There is plenty of work to do, but we
> really don't need some hacky, in-kernel buffer with hard coded audio
> formats.
> 
> Thanks,
> Richard
> 

[toc] | [prev] | [next] | [standalone]

#1421668

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jun 13, 2016 at 08:56:44AM -0700, John Fastabend wrote:
> On 16-06-13 04:47 AM, Richard Cochran wrote:
> > [...]
> > Here is what is missing to support audio TSN:
> > 
> > * User Space
> > 
> > 1. A proper userland stack for AVDECC, MAAP, FQTSS, and so on.  The
> >    OpenAVB project does not offer much beyond simple examples.
> > 
> > 2. A user space audio application that puts it all together, making
> >    use of the services in #1, the linuxptp gPTP service, the ALSA
> >    services, and the network connections.  This program will have all
> >    the knowledge about packet formats, AV encodings, and the local HW
> >    capabilities.  This program cannot yet be written, as we still need
> >    some kernel work in the audio and networking subsystems.
> > 
> > * Kernel Space
> > 
> > 1. Providing frames with a future transmit time.  For normal sockets,
> >    this can be in the CMESG data.  For mmap'ed buffers, we will need a
> >    new format.  (I think Arnd is working on a new layout.)
> > 
> > 2. Time based qdisc for transmitted frames.  For MACs that support
> >    this (like the i210), we only have to place the frame into the
> >    correct queue.  For normal HW, we want to be able to reserve a time
> >    window in which non-TSN frames are blocked.  This is some work, but
> >    in the end it should be a generic solution that not only works
> >    "perfectly" with TSN HW but also provides best effort service using
> >    any NIC.
> > 
> 
> When I looked at this awhile ago I convinced myself that it could fit
> fairly well into the DCB stack (DCB is also part of 802.1Q). A lot of
> the traffic class to queue mappings and priories could be handled here.
> It might be worth taking a look at ./net/sched/mqprio.c and ./net/dcb/.

Interesting, I'll have a look at dcb and mqprio, I'm not familiar with 
those systems. Thanks for pointing those out!

I hope that the complexity doesn't run crazy though, TSN is not aimed at 
datacentra, a lot of the endpoints are going to be embedded devices, 
introducing a massive stack for handling every eventuality in 802.1q is 
going to be counter productive.

> Unfortunately I didn't get too far along but we probably don't want
> another mechanism to map hw queues/tcs/etc if the existing interfaces
> work or can be extended to support this.

Sure, I get that, as long as the complexity for setting up a link doesn't 
go through the roof :)

Thanks!

-- 
Henrik Austad

[toc] | [prev] | [next] | [standalone]

#1421277

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.

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.

I don't know if ALSA has anything for sample rate conversion or not,
but haven't seen anything that addresses distributed synchronized
audio applications.

Thanks,
Richard

[toc] | [prev] | [next] | [standalone]

#1421775

On Mon, 13 Jun 2016 21:51:36 +0200
Richard Cochran <richardcochran@gmail.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

[toc] | [prev] | [next] | [standalone]

#1422106

On Tue, Jun 14, 2016 at 12:18:44PM +0100, One Thousand Gnomes wrote:
> On Mon, 13 Jun 2016 21:51:36 +0200
> Richard Cochran <richardcochran@gmail.com> wrote:
> > 
> > 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.

Well, I guess I should have said, I am not too familiar with the
breadth of current audio hardware, high end or low end.  Of course I
would like to see even consumer devices work with AVB, but it is up to
the ALSA people to make that happen.  So far, nothing has been done,
afaict.

Thanks,
Richard

[toc] | [prev] | [next] | [standalone]

#1422532

Hi Richard,

 > 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.
 >>
 >> 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?

The similar mechanism to synchronize endpoints was also applied to audio 
and music unit on IEEE 1394 bus. According to IEC 61883-1/6, some of 
these actual units can generate presentation-timestamp from header 
information of 8,000 packet per sec, and utilize the signal as sampling 
clock[1].

There's much differences between IEC 61883-1/6 on IEEE 1394 bus and 
Audio and Video Bridge on Ethernet[2], especially for synchronization, 
but in this point of transferring synchnization signal and time-based 
data, we have the similar requirements of software implementations, I think.

My motivation to join in this discussion is to consider about to make it 
clear to implement packet-oriented drivers in ALSA kernel-land, and 
enhance my work for drivers to handle IEC 61883-1/6 on IEEE 1394 bus.

 >> I don't know if ALSA has anything for sample rate conversion or not,
 >> but haven't seen anything that addresses distributed synchronized
 >> audio applications.

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.

Before establishing a PCM substream, userspace applications and 
in-kernel drivers communicate to decide sampling rate, PCM frame format, 
the size of PCM buffer, and so on. (see snd_pcm_hw_params() and 
ioctl(SNDRV_PCM_IOCTL_HW_PARAMS)). Thus, as long as in-kernel drivers 
know specifications of endpoints, userspace applications can start PCM 
substreams correctly.


[1] In detail, please refer to specification of 1394TA I introduced:
http://www.spinics.net/lists/netdev/msg381259.html
[2] I guess that IEC 61883-1/6 packet for Ethernet-AVB is a mutant from 
original specifications.


Regards

Takashi Sakamoto

[toc] | [prev] | [next] | [standalone]

#1422761

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

[toc] | [prev] | [next] | [standalone]

#1425647

Hi,

Sorry to be late. In this weekday, I have little time for this thread
because working for alsa-lib[1]. Besides, I'm not full-time developer
for this kind of work. In short, I use my limited private time for this
discussion.

On Jun 15 2016 17:06, Richard Cochran wrote:
> 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 ;)

In this morning, I read IEEE 1722:2011 and realized that it quite
roughly refers to IEC 61883-1/6 and includes much ambiguities to end
applications.

(In my opinion, the author just focuses on packet with timestamps,
without enough considering about how to implement endpoint applications
which perform semi-real sampling, fetching and queueing and so on, so as
you. They're satisfied just by handling packet with timestamp, without
enough consideration about actual hardware/software applications.)

> 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. ]

Depends on which subsystem decides "AVTP presentation time"[3]. 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.

As long as I know, the number of AVTPDU per second seems not to be
fixed. So each application is not allowed to calculate the timestamp by
its own way unless TSN implementation gives the information to each
applications.

For your information, in current ALSA implementation of IEC 61883-1/6 on
IEEE 1394 bus, the presentation timestamp is decided in ALSA side. The
number of isochronous packet transmitted per second is fixed by 8,000 in
IEEE 1394, and the number of data blocks in an IEC 61883-1 packet is
deterministic according to 'sampling transfer frequency' in IEC 61883-6
and isochronous cycle count passed from Linux FireWire subsystem.

In the TSN subsystem, like FireWire subsystem, callback for filling
payload should have information of 'when the packet is scheduled to be
transmitted'. With the information, each application can calculate the
number of event in the packet and presentation timestamp. Of cource,
this timestamp should be handled as 'avtp_timestamp' in packet queueing.

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

In ALSA kernel/userspace interfaces , the specification cannot be
supported, at all.

Please explain about this requirement, where it comes from, which
specification and clause describe it (802.1AS or 802.1Q?). As long as I
read IEEE 1722, I cannot find such a requirement.

(When considering about actual hardware codecs, on-board serial bus such
as Inter-IC Sound, corresponding controller, immediate change of
sampling rate is something imaginary for semi-realtime applications. And
the idea has no meaning for typical playback/capture softwares.)


[1] [alsa-lib][PATCH 0/9 v3] ctl: add APIs for control element set
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-June/109274.html
[2] IEEE 1722-2011
http://ieeexplore.ieee.org/servlet/opac?punumber=5764873
[3] 5.5 Timing and Synchronization
op. cit.
[4] 1394 Open Host Controller Interface Specification
http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/ohci_11.pdf


Regards

Takashi Sakamoto

[toc] | [prev] | [next] | [standalone]

#1425872

[Multipart message — attachments visible in raw view] — view raw

On Sat, Jun 18, 2016 at 02:22:13PM +0900, Takashi Sakamoto wrote:
> Hi,

Hi Takashi,

You raise a lot of valid points and questions, I'll try to answer them.

edit: this turned out to be a somewhat lengthy answer. I have tried to 
shorten it down somewhere. it is getting late and I'm getting increasingly 
incoherent (Richard probably knows what I'm talking about ;) so I'll stop 
for now.

Plase post a follow-up with everything that's not clear!
Thanks!

> Sorry to be late. In this weekday, I have little time for this thread
> because working for alsa-lib[1]. Besides, I'm not full-time developer
> for this kind of work. In short, I use my limited private time for this
> discussion.

Thank you for taking the time to reply to this thread then, it is much 
appreciated

> On Jun 15 2016 17:06, Richard Cochran wrote:
> > 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 ;)
> 
> In this morning, I read IEEE 1722:2011 and realized that it quite
> roughly refers to IEC 61883-1/6 and includes much ambiguities to end
> applications.

As far as I know, 1722 aims to describe how the data is wrapped in AVTPDU 
(and likewise for control-data), not how the end-station should implement 
it.

If there are ambiguities, would you mind listing a few? It would serve as a 
useful guide as to look for other pitfalls as well (thanks!)

> (In my opinion, the author just focuses on packet with timestamps,
> without enough considering about how to implement endpoint applications
> which perform semi-real sampling, fetching and queueing and so on, so as
> you. They're satisfied just by handling packet with timestamp, without
> enough consideration about actual hardware/software applications.)

You are correct, none of the standards explain exactly how it should be 
implemented, only what the end result should look like. One target of this 
collection of standards are embedded, dedicated AV equipment and the 
authors have no way of knowing (nor should they care I think) the 
underlying architecture of these.

> > Here is what I think ALSA should provide:
> > 
> > - The DA and AD clocks should appear as attributes of the HW device.

This would be very useful and helpful when determining if the clock of the 
HW time is falling behind or racing ahead of the gPTP time domain. It will 
also help finding the capture time or calculating when a sample in the 
buffer will be played back by the 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.

as above.

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

This is not a requirement from the standard, but will help avoid costly 
resampling. At least it should be possible to detect the *need* for 
resampling so that we can try to avoid underruns.

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

yes, if you have multiple microphones that you want to combine into a 
stream and do signal processing, some cases require sample-sync (so within 
1 us accuracy for 48kHz).

> > - 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. ]
> 
> Depends on which subsystem decides "AVTP presentation time"[3]. 

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.

> As long as I know, the number of AVTPDU per second seems not to be
> fixed. So each application is not allowed to calculate the timestamp by
> its own way unless TSN implementation gives the information to each
> applications.

Before initiating a stream, an application needs to reserve a path and 
bandwidth through the network. Every bridge (switch/router) must accept 
this for the stream-allocation to succeed. If a single bridge along the way 
declies, the entire stream is denied. The StreamID combined with traffic 
class and destination address is used to uniquely identify the stream.

Once ready, frames leaving the End-station with the same StreamID will be 
forwarded through the bridges to the End-station(s).

If you choose to transmit *less* than the bandwidth you reserved, that is 
fine, but you cannot transmit *more*.

As to timestamps. When a talker transmit a frame, the timestamp in the 
AVTPDU describes the presentation-time.

1) The Talker is a mic, and the timestamp will then be the capture-time 
   of the sample.
2) For a Listener, the timestamp will be the presentation-time, 
   the time when the *first* sample in the sample-set should be played (or 
   aligned in an offline format with other samples).

The application should be part of the same gPTP-domain as all the other 
nodes in the domain, and all the nodes share a common sense of time. That 
means that time X will be the exact same time (or, within a sub-microsecond 
error) for all the nodes in the same domain.

> For your information, in current ALSA implementation of IEC 61883-1/6 on
> IEEE 1394 bus, the presentation timestamp is decided in ALSA side. The
> number of isochronous packet transmitted per second is fixed by 8,000 in
> IEEE 1394, and the number of data blocks in an IEC 61883-1 packet is
> deterministic according to 'sampling transfer frequency' in IEC 61883-6
> and isochronous cycle count passed from Linux FireWire subsystem.

For an audio-stream, it will be very similar. The difference is the split 
between class A and class B, the former is 8kHz frame-rate and a guaranteed 
2ms latency accross the network (think required buffering at end-stations), 
class B is 4kHz and a 50ms max latency. Class B is used for links 
traversing 1 or 2 wireless links.

If you look at the avb-shim in the series, you see that for 48kHz, 2ch, 
S16_LE, every frame is of the same size, 6 samples per frame, total of 24 
bytes / frame. For class B, size doubles to 48 bytes as it transmits frames 
4000 times / sec.

The 44.1 part is a bit more painful/messy/horrible, but is doable because 
the stream-reservation only gives an *upper* bound of bandwidth.

> In the TSN subsystem, like FireWire subsystem, callback for filling
> payload should have information of 'when the packet is scheduled to be
> transmitted'. 

[ Given that you are part of a gPTP domain and that you share a common 
  sense of what time it is *now* with all the other devices ]

A frame should be transmittet so that it will not arrive too late for it to 
be presented. A class A link guarantees that a frame will be delivered 
within 2ms. Then, by looking at the timestamp, you subtract the 
delivery-time and you get when the frame should be sent at the latest.

> With the information, each application can calculate the
> number of event in the packet and presentation timestamp. Of cource,
> this timestamp should be handled as 'avtp_timestamp' in packet queueing.

Not sure if I understand what you are asking, but I think maybe I've 
answered this above (re. 48kHz, 44.1khz and upper bound of framesize?)

> >> 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?
> 
> In ALSA kernel/userspace interfaces , the specification cannot be
> supported, at all.
> 
> Please explain about this requirement, where it comes from, which
> specification and clause describe it (802.1AS or 802.1Q?). As long as I
> read IEEE 1722, I cannot find such a requirement.

1722 only describes how the L2 frames are constructed and transmittet. You 
are correct that it does not mention adjustable clocks there.

- 802.1BA gives an overview of AVB

- 802.1Q-2011 Sec 34 and 35 describes forwarding and queueing and Stream 
  Reservation (basically what the network needs in order to correctly 
  prioritize TSN streams)

- 802.1AS-2011 (gPTP) describes the timing in great detail (from a PTP 
  point of vew) and describes in more detail how the clocks should be 
  syntonized (802.1AS-2011, 7.3.3).

Since the clock that drives the sample-rate for the DA/AD must be 
controlled by the shared clock, the fact that gPTP can adjust the time 
means that the DA/AD circuit needs to be adjustable as well.

note that an adjustable sample-clock is not a *requirement* but in general 
you'd want to avoid resampling in software.

> (When considering about actual hardware codecs, on-board serial bus such
> as Inter-IC Sound, corresponding controller, immediate change of
> sampling rate is something imaginary for semi-realtime applications. And
> the idea has no meaning for typical playback/capture softwares.)

Yes, and no. When you play back a stored file to your soundcard, data is 
pulled by the card from memory. So you only have a single timing-domain to 
worry about. So I'd say the idea has meaning in normal scenarios as well, 
you don't have to worry about it.

When you send a stream accross the network, you cannot let the Listener 
pull data from you, you have to have some common sense of time in order to 
send just enough data, and that is why the gPTP domain is so important.

802.1Q gives you low latency through the network, but more importantly, no 
dropped frames. gPTP gives you a central reference to time.

> [1] [alsa-lib][PATCH 0/9 v3] ctl: add APIs for control element set
> http://mailman.alsa-project.org/pipermail/alsa-devel/2016-June/109274.html
> [2] IEEE 1722-2011
> http://ieeexplore.ieee.org/servlet/opac?punumber=5764873
> [3] 5.5 Timing and Synchronization
> op. cit.
> [4] 1394 Open Host Controller Interface Specification
> http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/ohci_11.pdf

I hope this cleared some of the questions

-- 
Henrik Austad

[toc] | [prev] | [next] | [standalone]

#1425953

On Sun, Jun 19, 2016 at 12:45:50AM +0200, Henrik Austad wrote:
> edit: this turned out to be a somewhat lengthy answer. I have tried to 
> shorten it down somewhere. it is getting late and I'm getting increasingly 
> incoherent (Richard probably knows what I'm talking about ;) so I'll stop 
> for now.

Thanks for your responses, Henrik.  I think your explanations are on spot.

> note that an adjustable sample-clock is not a *requirement* but in general 
> you'd want to avoid resampling in software.

Yes, but..

Adjusting the local clock rate to match the AVB network rate is
essential.  You must be able to *continuously* adjust the rate in
order to compensate drift.  Again, there are exactly two ways to do
it, namely in hardware (think VCO) or in software (dynamic
resampling).

What you cannot do is simply buffer the AV data and play it out
blindly at the local clock rate.

Regarding the media clock, if I understand correctly, there the talker
has two possibilities.  Either the talker samples the stream at the
gPTP rate, or the talker must tell the listeners the relationship
(phase offset and frequency ratio) between the media clock and the
gPTP time.  Please correct me if I got the wrong impression...

Thanks,
Richard

[toc] | [prev] | [next] | [standalone]

#1426437

[Multipart message — attachments visible in raw view] — view raw

On Sun, Jun 19, 2016 at 11:46:29AM +0200, Richard Cochran wrote:
> On Sun, Jun 19, 2016 at 12:45:50AM +0200, Henrik Austad wrote:
> > edit: this turned out to be a somewhat lengthy answer. I have tried to 
> > shorten it down somewhere. it is getting late and I'm getting increasingly 
> > incoherent (Richard probably knows what I'm talking about ;) so I'll stop 
> > for now.
> 
> Thanks for your responses, Henrik.  I think your explanations are on spot.
> 
> > note that an adjustable sample-clock is not a *requirement* but in general 
> > you'd want to avoid resampling in software.
> 
> Yes, but..
> 
> Adjusting the local clock rate to match the AVB network rate is
> essential.  You must be able to *continuously* adjust the rate in
> order to compensate drift.  Again, there are exactly two ways to do
> it, namely in hardware (think VCO) or in software (dynamic
> resampling).

Don't get me wrong, having an adjustable clock for the sampling is 
essential -but it si not -required-.

> What you cannot do is simply buffer the AV data and play it out
> blindly at the local clock rate.

No, that you cannot do that, that would not be pretty :)

> Regarding the media clock, if I understand correctly, there the talker
> has two possibilities.  Either the talker samples the stream at the
> gPTP rate, or the talker must tell the listeners the relationship
> (phase offset and frequency ratio) between the media clock and the
> gPTP time.  Please correct me if I got the wrong impression...

Last first; AFAIK, there is no way for the Talker to tell a Listener the 
phase offset/freq ratio other than how each end-station/bridge in the 
gPTP-domain calculates this on psync_update event messages. I could be 
wrong though, and different encoding formats can probably convey such 
information. I have not seen any such mechanisms in the underlying 1722 
format though.

So a Talker should send a stream sampled as if the gPTP time drove the 
AD/DA sample frequency directly. Whether the local sampling is driven by 
gPTP or resampled to match gPTP-time prior to transmit is left as an 
implementation detail for the end-station.

Did all that make sense?

Thanks!
-- 
Henrik Austad

[toc] | [prev] | [next] | [standalone]

#1426506 — 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.

[toc] | [prev] | [next] | [standalone]

#1426521 — Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jun 20, 2016 at 01:08:27PM +0200, Pierre-Louis Bossart wrote:
> 
> >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.

Ok, this sounds promising, and very much in line with what AVB would need.

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

Ok, I understand that the 'play_at' is difficult to obtain, but it sounds 
like it is doable to achieve something useful.

Looks like I will be looking into what to put in the .trigger-handler in 
the ALSA shim and experimenting with this to see how it make sense to 
connect it from the TSN-stream.

Thanks!

-- 
Henrik Austad

[toc] | [prev] | [next] | [standalone]

#1426548 — Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

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


Thanks,
Richard

[toc] | [prev] | [next] | [standalone]

#1426576 — Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

On Mon, Jun 20, 2016 at 02:18:38PM +0200, Richard Cochran wrote:
> Documentation/sound/alsa/timestamping.txt says:

   Examples of typestamping with HDaudio:

   1. DMA timestamp, no compensation for DMA+analog delay
   $ ./audio_time  -p --ts_type=1

Where is this "audio_time" program of which you speak?

Thanks,
Richard

[toc] | [prev] | [next] | [standalone]

#1426701 — Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

On Mon, Jun 20, 2016 at 02:31:48PM +0200, Richard Cochran wrote:
> Where is this "audio_time" program of which you speak?

Never mind, found it in alsa-lib.

I still would appreciate an answer to my other questions, though...
 
Thanks,
Richard

[toc] | [prev] | [next] | [standalone]

#1427333 — Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

On Mon, 20 Jun 2016 17:21:26 +0200,
Richard Cochran wrote:
> 
> On Mon, Jun 20, 2016 at 02:31:48PM +0200, Richard Cochran wrote:
> > Where is this "audio_time" program of which you speak?
> 
> Never mind, found it in alsa-lib.
> 
> I still would appreciate an answer to my other questions, though...

Currently HD-audio (both ASoC and legacy ones) are the only drivers
providing the link timestamp.  In the recent code, it's PCM
get_time_info ops, so you can easily grep it.


HTH,

Takashi

[toc] | [prev] | [next] | [standalone]

#1427347 — Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

On Tue, Jun 21, 2016 at 07:54:32AM +0200, Takashi Iwai wrote:
> > I still would appreciate an answer to my other questions, though...
> 
> Currently HD-audio (both ASoC and legacy ones) are the only drivers
> providing the link timestamp.  In the recent code, it's PCM
> get_time_info ops, so you can easily grep it.

Yes, I found that myself, thanks.
 
> HTH,

No it doesn't help me, because I asked three questions, and none were
about the link timestamp.

Thanks,
Richard

[toc] | [prev] | [next] | [standalone]

#1427352 — Re: [alsa-devel] [very-RFC 0/8] TSN driver for the kernel

On Tue, 21 Jun 2016 08:38:57 +0200,
Richard Cochran wrote:
> 
> On Tue, Jun 21, 2016 at 07:54:32AM +0200, Takashi Iwai wrote:
> > > I still would appreciate an answer to my other questions, though...
> > 
> > Currently HD-audio (both ASoC and legacy ones) are the only drivers
> > providing the link timestamp.  In the recent code, it's PCM
> > get_time_info ops, so you can easily grep it.
> 
> Yes, I found that myself, thanks.
>  
> > HTH,
> 
> No it doesn't help me, because I asked three questions, and none were
> about the link timestamp.

??  The extended audio timpestamp is essentially to return the link
timestamp.  Just the term has changed along time...


Takashi

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.kernel

csiph-web