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