All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: [PATCH] ALSA: pcm - introduce soc_delay
Date: Mon, 23 Jul 2012 21:05:12 +0100	[thread overview]
Message-ID: <20120723200512.GB25707@sirena.org.uk> (raw)
In-Reply-To: <500DAB54.20705@linux.intel.com>

On Mon, Jul 23, 2012 at 02:51:48PM -0500, Pierre-Louis Bossart wrote:
> On 7/23/2012 5:47 AM, Mark Brown wrote:

Don't drop CCs from replies.

> >I'm having a hard time relating this to what I was saying.  The point
> >here is that if the device keeps marching on consuming data (as most
> >cyclic DMAs would) then there's still going to be an underrun even if
> >there's a buffer that causes a delay in the user hearing it

> Not necessarily. The DMA between system memory and DSP buffers need
> not work at a rate linked to the serial bit clock, they can be much
> faster, and actually they should to help put the system in a low
> power state rather than reading continuously from memory... what

I'm aware of this, thanks.

> Vinod is trying to explain is that due to the bursty nature of data
> transfers inside the soc, we need to modify how the accounting is
> done.

Right, but this depends on the ability of the device to pause reading
data when it reads up to the point where the application has written.
This is a separate capability to any latency that's been added by the
buffering, and most of the systems that have the buffering don't have
this capability but instead either don't report the buffer or rely on
the application being a full buffer ahead of the hardware.

  reply	other threads:[~2012-07-23 20:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-23 10:06 [PATCH] ALSA: pcm - introduce soc_delay Vinod Koul
2012-07-23 10:18 ` Mark Brown
2012-07-23 10:39   ` Vinod Koul
2012-07-23 10:47     ` Mark Brown
2012-07-23 11:06       ` Vinod Koul
2012-07-23 13:47         ` Mark Brown
2012-07-23 19:51       ` Pierre-Louis Bossart
2012-07-23 20:05         ` Mark Brown [this message]
2012-07-23 20:16           ` Pierre-Louis Bossart
2012-07-23 21:27             ` Mark Brown
2012-07-23 14:21     ` Jassi Brar
2012-07-23 10:19 ` Jassi Brar
2012-07-23 10:39   ` Vinod Koul
2012-07-23 10:50     ` Jassi Brar
2012-07-23 11:17       ` Vinod Koul
2012-07-23 11:23         ` Mark Brown
2012-07-23 13:37         ` Jassi Brar
2012-07-23 10:27 ` Takashi Iwai
2012-07-23 10:47   ` Vinod Koul
2012-07-23 10:47   ` Jaroslav Kysela
2012-07-23 11:14     ` Vinod Koul

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=20120723200512.GB25707@sirena.org.uk \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=pierre-louis.bossart@linux.intel.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.