public inbox for alsa-devel@alsa-project.org
 help / color / mirror / Atom feed
From: Shine Liu <shinel@foxmail.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: [PATCH] pcm_lib.c: Fixed inaccurate calculation of hw_ptr_interrupt in snd_pcm_update_hw_ptr_interrupt function
Date: Thu, 20 Aug 2009 15:20:42 +0800	[thread overview]
Message-ID: <1250752842.5644.34.camel@shinel> (raw)
In-Reply-To: <s5hocqcarrx.wl%tiwai@suse.de>

On Wed, 2009-08-19 at 14:53 +0200, Takashi Iwai wrote:
> At Wed, 19 Aug 2009 12:48:26 +0000,
> Shine Liu wrote:
> > 
> > On Wed, 2009-08-19 at 14:05 +0200, Takashi Iwai wrote:
> > > > 
> > > > But the irq last issued should be at 0x3e80, but not 0x3800 + 0x800 =
> > > > 0x4000. The DMA engine loaded 0x680 frame not 0x800 frame at the last
> > > > time.
> > > 
> > > Then it's a driver bug.  If unaligned period size is allowed, it means
> > > that the irq is really generated in that period, not at the buffer
> > > boundary.  Otherwise, it must have a proper hw-constraint to align the
> > > period size to the buffer size.

Hi, Takashi

    I carefully read the pcm_lib.c and pcm_native.c but I didn't found
any alignmnet constraint API. Althought there's a function called
snd_pcm_hw_constraint_step, but this function can't be used in the
situation referred in the last mail which one hw parameter should be
aligned to the other hw parameter.

    I've implement a snd_pcm_hw_constraint_aligned function based on
snd_interval_step.

    The patch is based on linux-2.6.31-rc6, and I've tested.


Signed-off-by: Shine Liu <shinel@foxmail.com>
-------------------------------------------------------------------

--- a/include/sound/pcm.h	2009-08-14 06:43:34.000000000 +0800
+++ b/include/sound/pcm.h	2009-08-20 14:29:13.000000000 +0800
@@ -790,6 +790,10 @@
 			       unsigned int cond,
 			       snd_pcm_hw_param_t var,
 			       unsigned long step);
+int snd_pcm_hw_constraint_aligned(struct snd_pcm_runtime *runtime,
+			       unsigned int cond,
+			       snd_pcm_hw_param_t var,
+			       snd_pcm_hw_param_t unit);
 int snd_pcm_hw_constraint_pow2(struct snd_pcm_runtime *runtime,
 			       unsigned int cond,
 			       snd_pcm_hw_param_t var);
--- a/sound/core/pcm_lib.c	2009-08-19 13:12:47.000000000 +0800
+++ b/sound/core/pcm_lib.c	2009-08-20 14:25:53.000000000 +0800
@@ -1319,6 +1319,33 @@
 
 EXPORT_SYMBOL(snd_pcm_hw_constraint_step);
 
+static int snd_pcm_hw_rule_aligned(struct snd_pcm_hw_params *params,
+				struct snd_pcm_hw_rule *rule)
+{
+	struct snd_interval * i = hw_param_interval(params, rule->deps[0]);
+	unsigned int unit = snd_interval_value(i);
+	return snd_interval_step(hw_param_interval(params, rule->var), 0, unit);
+}
+
+/**
+ * snd_pcm_hw_constraint_aligned - add a hw constraint alignment rule
+ * @runtime: PCM runtime instance
+ * @cond: condition bits
+ * @var: hw_params variable to apply the alignment constraint
+ * @unit: hw_params variable to provid the alignment unit
+ */
+int snd_pcm_hw_constraint_aligned(struct snd_pcm_runtime *runtime,
+			       unsigned int cond,
+			       snd_pcm_hw_param_t var,
+			       snd_pcm_hw_param_t unit)
+{
+	return snd_pcm_hw_rule_add(runtime, cond, var, 
+				   snd_pcm_hw_rule_aligned, (void *) 0,
+				   unit, -1);
+}
+
+EXPORT_SYMBOL(snd_pcm_hw_constraint_aligned);
+
 static int snd_pcm_hw_rule_pow2(struct snd_pcm_hw_params *params, struct snd_pcm_hw_rule *rule)
 {
 	static unsigned int pow2_sizes[] = {


> > > 
> > > What hardware is it?
> > 
> > Yes, but there's no constraint code currently to force to align the
> > period size to the buffer size. The bug occurs on linux-2.6.31-rc6 on
> > ASoC s3c24xx platform.
> > 
> > The constraint to force to align the period size to the buffer size
> > should not be hardware depended, it shoud be done in the generic layer,
> > is it?
> 
> It is hardware dependent, i.e. how the irq is generated.
> If the irq is generated in a way like timer, the period size doesn't
> have to be aligned with the buffer size.  But your case doesn't look
> like that.
> 
> 
> Takashi
> 
> 
> 

  parent reply	other threads:[~2009-08-20  7:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-19 10:22 [PATCH] pcm_lib.c: Fixed inaccurate calculation of hw_ptr_interrupt in snd_pcm_update_hw_ptr_interrupt function Shine Liu
2009-08-19 10:34 ` Takashi Iwai
2009-08-19 10:59   ` Shine Liu
2009-08-19 12:05     ` Takashi Iwai
2009-08-19 12:48       ` Shine Liu
2009-08-19 12:53         ` Takashi Iwai
2009-08-19 13:01           ` Shine Liu
2009-08-20  7:20           ` Shine Liu [this message]
2009-08-20  8:42             ` Clemens Ladisch
2009-08-20 15:02       ` [PATCH] ASoC: S3C24XX : Align the peroid size to the buffer size Shine Liu
2009-08-20 18:44         ` Mark Brown

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=1250752842.5644.34.camel@shinel \
    --to=shinel@foxmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=tiwai@suse.de \
    /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