### Question on HW Pointer

### Question on HW Pointer

[Steve Spano]

Hello Folks,

 

I am wondering if someone can help clarify how the hw pointer is used by the
ALSA layer.

I have a 24 channel soundcard that we have developed, using a Xilinx fpga.

The system is working, in that I can receive inbound samples on all 24
inputs and transmit samples on all 24 outputs.

 

But something isn't completely right.

 

We can xrun's and reports of very high cpu utilization.even though I know we
are in and out of our interrupts within 100uS for a 2.7mS interrupt period.

Interesting that our xruns cite a "0mS delay" or sometimes a 4mS delay (1.5
periods?)

 

I think the issue has to do with how we are presenting the response to the
hw-pointer request OR how/when we are calling the pcm_snd_elapsed.

 

I think the flow should be as follows (lets consider the dac part)

 

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

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?

 

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?

 

Thanks again

 

Steve Spano

Re: ### Question on HW Pointer

[Clemens Ladisch]

Steve Spano wrote:
> I think the flow should be as follows (lets consider the dac part)
> 
> Step #1 ) interrupt occurs
> Step #2) dma/transfer begins as kicked off in interrupt routine

So I assume the driver is responsible for telling the hardware to begin
transferring the next period.  Doesn't it do this automatically?

> Step #3) we advance the buffer pointer for the alsa buffer

An interrupt (that is, for ALSA, the call to snd_pcm_period_elapsed)
signals the end of the previous period.

> 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

The pointer callback can be called at any time.  It will definitely be
called from snd_pcm_period_elapsed, so the buffer pointer must already
have been increased before that call.

> And then we return the current value of the hardware pointer from the board?

Drop the word "then"; the pointer callback _always_ must return the
current value. :)

> So alsa knows how many samples the board has processed from the interrupt?

Yes; ALSA (or the application) wants to know how many samples the board
has processed.  If your DMA controller does not have a register for this,
the pointer must be calculated and updated in the interrupt handler (as
you do).

> 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?

This, and to know which part of the buffer can be written to (the
hardware pointer indicates which part of the buffer has been processed
by the hardware; the samples after the pointer will be read now or
later).


Regards,
Clemens

Re: Question on HW Pointer

[Eliot Blennerhassett]

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.