[alsa-devel] ### Question on HW Pointer
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
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
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?
participants (3)
-
Clemens Ladisch -
Eliot Blennerhassett -
Steve Spano