alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Eliot Blennerhassett <linux@audioscience.com>
To: Steve Spano <steve@fl-eng.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: Question on HW Pointer
Date: Wed, 06 Oct 2010 20:15:46 +1300	[thread overview]
Message-ID: <4CAC2222.6090903@audioscience.com> (raw)
In-Reply-To: <001201cb64ee$5beec5c0$13cc5140$@fl-eng.com>

Hi Steve,

the usual refrain is "show us the code" - please do so, as it is much
easier to see the details of where you may be going wrong.

Also can you describe in a bit more detail how your DMA engine behaves.


On 06/10/10 13:35, Steve Spano wrote:
> Step #1 ) interrupt occurs
> 
> Step #2) dma/transfer begins as kicked off in interrupt routine
> 
> Step #3) we advance the buffer pointer for the alsa buffer
> 
> Step #4) we exit the interrupt
> 
> . then the hardware should start advancing its pointer as it is reading the
> new samples
> 
> .. then sometime later, the alsa layer calls the "hw_pointer" function

0) ALSA puts some data in the dma buffer, probably at least 2 periods.

1) In trigger callback,case SNDRV_PCM_TRIGGER_START kick off dma,
assuming for now that the DMA free-runs around the buffer forever,
the buffer size is >= 2 periods,
and your hardware can interrupt every time the DMA has transferred one
period.

2) later, in interrupt, call period_elapsed (assuming it has!)
this lets ALSA midlevel know that one period worth of the buffered data
has been consumed, and free to be written with new data.

> And then we return the current value of the hardware pointer from the board?
> So alsa knows how many samples the board has processed from the interrupt?

If you can read the exact read pointer position from your DMA engine,
then use that in the pointer callback.
(Be sure to convert to frames first),
otherwise, in your interrupt routine keep track of where the DMA has
read and use that.

> We should be pretty close, because it is working for the most part..but I
> think this pointer is not right. 
> 
> Can someone explain how this pointer/etc is supposed to flow and what alsa
> may be using it for? Maybe some latency calculation in a an upper layer?


-- 
Eliot Blennerhassett
AudioScience Inc.

      parent reply	other threads:[~2010-10-06  7:15 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-06  0:35 ### Question on HW Pointer Steve Spano
2010-10-06  6:46 ` Clemens Ladisch
2010-10-06  7:15 ` Eliot Blennerhassett [this message]

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=4CAC2222.6090903@audioscience.com \
    --to=linux@audioscience.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=steve@fl-eng.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).