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?