All of lore.kernel.org
 help / color / mirror / Atom feed
From: Raymond Yau <superquad.vortex2@gmail.com>
To: Alan Young <consult.awy@gmail.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: Improving status timestamp accuracy
Date: Sun, 5 Jun 2016 09:14:41 +0800	[thread overview]
Message-ID: <CAN8cciZN=Gjq3Za+Qz31EYoCsTuTNp4au_Upxq8ZvvEJqNdw9w@mail.gmail.com> (raw)
In-Reply-To: <5752A005.2050309@gmail.com>

2016-06-04 17:31 GMT+08:00 Alan Young <consult.awy@gmail.com>:

> I am looking at ways to get more accurate status timestamp information for
> various SoC drivers. The data that is obtained by snd_pcm_status(). One
> route would be to implement the more accurate timestamp mechanisms that
> currently are only available for HDA and Skylake (which I think is the SoC
> version of HDA).
>
> Looking at the code however, I think that may be unnecessary, at least for
> my purposes. It may not actually be practical in many cases.
>
> A call to snd_pcm_status() result in snd_pcm_update_hw_ptr0() being
> called. This gets the current output position (pos) via
> substream->ops->pointer(substream) and then makes all the other
> calculations based on the result. In theory, the result of
> substream->ops->pointer() could be sample accurate but in practice it is
> very unlikely to be better than period accurate. In fact, if I read it
> right, it will just about always be accurate to the point of the last
> period interrupt. Even when a DMA driver claims support of
> DMA_RESIDUE_GRANULARITY_BURST, it is often the case that the actual
> granularity is a period.
>

the point only increment in DMA brust size , so it is not sample accurate

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/include/linux/dmaengine.h

* @DMA_RESIDUE_GRANULARITY_BURST: Residue is updated after each transferred

 *  burst. This is typically only supported if the hardware has a
progress *  register of some sort (E.g. a register with the current
read/write address *  or a register with the amount of
bursts/beats/bytes that have been *  transferred or still need to be
transferred).


if the driver point callback does not read from hardware register , it
should use


DMA_RESIDUE_GRANULARITY_DESCRIPTOR: Residue reporting is not support.
The *  DMA channel is only able to tell whether a descriptor has been
completed or *  not, which means residue reporting is not supported by
this channel. The *  residue field of the dma_tx_state field will
always be 0.




>
> The consequence of all that is that, for most drivers, the accuracy of a
> status report is period time. The result values, tstamp & audio_tstamp, are
> calculated using the current time and the pos estimate from above.
>



>
>
>
>

  parent reply	other threads:[~2016-06-05  1:14 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-04  9:31 Improving status timestamp accuracy Alan Young
2016-06-04 10:17 ` Clemens Ladisch
2016-06-04 10:43   ` Alan Young
2016-06-04 15:59     ` Clemens Ladisch
2016-06-04 16:20       ` Alan Young
2016-06-05 16:27         ` Clemens Ladisch
2016-06-05 16:32           ` Alan Young
2016-06-05  1:14 ` Raymond Yau [this message]
2016-06-05 10:33   ` Alan Young
2016-06-06  1:24     ` Raymond Yau
2016-06-06  9:40       ` Alan Young
2016-06-06  8:34     ` Takashi Iwai
2016-06-06  9:42       ` Alan Young
2016-06-06 14:53         ` Pierre-Louis Bossart
2016-06-07  6:44           ` Alan Young
2016-06-07 18:01             ` Pierre-Louis Bossart
2016-07-08 15:03             ` Alan Young
2016-07-15 20:13               ` Pierre-Louis Bossart
2016-07-19 15:33                 ` Alan Young
2016-07-19 15:58                   ` Pierre-Louis Bossart
2016-07-20  6:59                     ` Alan Young
2016-08-01 21:56                       ` Pierre-Louis Bossart
2016-08-02  7:30                         ` Alan Young
2016-08-02  7:55                           ` Clemens Ladisch
2016-08-02 16:25                           ` Pierre-Louis Bossart

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='CAN8cciZN=Gjq3Za+Qz31EYoCsTuTNp4au_Upxq8ZvvEJqNdw9w@mail.gmail.com' \
    --to=superquad.vortex2@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=consult.awy@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.