Timur Tabi wrote:
During capture, my hardware can take up to two milliseconds for the DMA to start transferring data to the buffer. This is because the internal FIFO needs to fill up before DMA starts.
Today, my .trigger function (during a START request) just waits until the FIFO is full before returning control back to ALSA. This seems to work, except that I wait by using a busy-loop. As you can imagine, a 2ms busy loop is not a good idea.
Especially as the trigger callback is called inside a spinlock with interrupts disabled.
An alternative idea is to have my .pointer function return 0 if DMA has not yet started. This appears to work, but I want to make sure it's a good idea.
My concern is that I might confuse ALSA because it is expecting some data in the buffer after capture has started. Is my approach correct?
0 is the only value that you can return in this situation, because any other value would imply that the buffer actually contains some valid data.
The USB driver has bigger delays when starting, and it works.
HTH Clemens