Accuracy of substream->ops->pointer?

Accuracy of substream->ops->pointer?

[Timur Tabi]

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.

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?

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: Accuracy of substream->ops->pointer?

[Clemens Ladisch]

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