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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
