From: Alan Young <consult.awy@gmail.com>
To: Raymond Yau <superquad.vortex2@gmail.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: Improving status timestamp accuracy
Date: Sun, 5 Jun 2016 11:33:20 +0100 [thread overview]
Message-ID: <5753FFF0.3050200@gmail.com> (raw)
In-Reply-To: <CAN8cciZN=Gjq3Za+Qz31EYoCsTuTNp4au_Upxq8ZvvEJqNdw9w@mail.gmail.com>
On 05/06/16 02:14, Raymond Yau wrote:
> 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.|
> |
Yes, I understand that. And that is exactly my point. Because of this a
pcm_status() result is only accurate to a granularity of period in most
cases.
In fact, some drivers, for example imx sdma, declare
DMA_RESIDUE_GRANULARITY_BURST accuracy because sometimes they may have
such an accuracy but in practice, at least for audio, they only actually
achieve period accuracy.
Regardless of what value of DMA_RESIDUE_GRANULARITY_xxx that a driver
claims to support, it is not really defined how fine a burst might be.
So the end result is, from the point of view of audio, that the
resulting position obtained by the pointer() call is pretty inaccurate.
Hence my proposal to attempt to improve the accuracy of the pcm_status()
result given the above constraints.
The following patch gives an idea of what I am considering:
diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c
index 6b5a811..ea5b525 100644
--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -234,7 +234,8 @@ int snd_pcm_update_state(struct snd_pcm_substream
*substream,
static void update_audio_tstamp(struct snd_pcm_substream *substream,
struct timespec *curr_tstamp,
- struct timespec *audio_tstamp)
+ struct timespec *audio_tstamp,
+ unsigned int adjust_existing_audio_tstamp)
{
struct snd_pcm_runtime *runtime = substream->runtime;
u64 audio_frames, audio_nsecs;
@@ -252,17 +253,23 @@ static void update_audio_tstamp(struct
snd_pcm_substream *substream,
* add delay only if requested
*/
- audio_frames = runtime->hw_ptr_wrap + runtime->status->hw_ptr;
+ if (adjust_existing_audio_tstamp &&
runtime->status->tstamp->tv_sec) {
+ struct timespec delta =
+ timespec_sub(*curr_tstamp, runtime->status->tstamp);
+ *audio_tstamp = timespec_add(*audio_tstamp, delta);
+ } else {
+ audio_frames = runtime->hw_ptr_wrap + runtime->status->hw_ptr;
- if (runtime->audio_tstamp_config.report_delay) {
- if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
- audio_frames -= runtime->delay;
- else
- audio_frames += runtime->delay;
+ if (runtime->audio_tstamp_config.report_delay) {
+ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+ audio_frames -= runtime->delay;
+ else
+ audio_frames += runtime->delay;
+ }
+ audio_nsecs = div_u64(audio_frames * 1000000000LL,
+ runtime->rate);
+ *audio_tstamp = ns_to_timespec(audio_nsecs);
}
- audio_nsecs = div_u64(audio_frames * 1000000000LL,
- runtime->rate);
- *audio_tstamp = ns_to_timespec(audio_nsecs);
}
runtime->status->audio_tstamp = *audio_tstamp;
runtime->status->tstamp = *curr_tstamp;
@@ -454,7 +461,7 @@ static int snd_pcm_update_hw_ptr0(struct
snd_pcm_substream *substream,
no_delta_check:
if (runtime->status->hw_ptr == new_hw_ptr) {
- update_audio_tstamp(substream, &curr_tstamp, &audio_tstamp);
+ update_audio_tstamp(substream, &curr_tstamp, &audio_tstamp,
!in_interrupt);
return 0;
}
@@ -479,7 +486,7 @@ static int snd_pcm_update_hw_ptr0(struct
snd_pcm_substream *substream,
runtime->hw_ptr_wrap += runtime->boundary;
}
- update_audio_tstamp(substream, &curr_tstamp, &audio_tstamp);
+ update_audio_tstamp(substream, &curr_tstamp, &audio_tstamp,
!in_interrupt);
return snd_pcm_update_state(substream, runtime);
}
next prev parent reply other threads:[~2016-06-05 10:33 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
2016-06-05 10:33 ` Alan Young [this message]
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=5753FFF0.3050200@gmail.com \
--to=consult.awy@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=superquad.vortex2@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.