[alsa-devel] [PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap
peter.ujfalusi at nokia.com
Fri Mar 12 07:18:30 CET 2010
On Friday 12 March 2010 00:43:41 ext Mark Brown wrote:
> I can do, though there was some debate about how useful the
> information the hardware returns actually is - could folks confirm
> what the consensus there was, please?
Yeah, that thread went silent without final go or no go...
I do agree with Eero, that the BUFFSTAT register is not the most reliable source
of information, but I still believe that the way we are going to use it will
give pretty close to the reality estimation on the statuses.
Eero also mentioned timestamp based estimation, which I think can also be used
in this way:
In element mode, we just return the delay as the whole size of the buffer (which
is not accurate when we initially fill the buffer, and when we drain it at the
end, but it is not a real problem).
In threshold mode, than we can take timestamp at DMA completion interrupts, and
calculate the delay based on the FIFO size (FIFO size - samples played out since
the last timstamp). This can also give false numbers at the start of the
playback (for few periods, until the buffer utilization settles).
So the timestamp based solution looks good, but it is only usable when the codec
is running synchronously. It will definitely falls apart as soon as we use a
codec like tlv320dac33 in burst mode (FIFO on the codec as well).
We could have ~100 ms between DMA interrupts, so the countdown for McBSP FIFO
usage is already broken.
Furthermore since there is no way at the moment to actually synchronize the
omap-mcbsp, omap-pcm and tlv320dac33 (in DMA, McBSP threshold, McBSP mode and
DAC33 mode sense), there could be cases, that this big silence on the bus (when
DAC33 is playing from it's buffer) is not happening exactly after the DMA filled
up the McBSP FIFO, but a bit later (could be just one sample away from the next
McBSP threshold event), which means that the McBSP FIFO is nowhere near to be
In this case the BUFFSTAT register would give good estimation, than any
timestamp based solution for McBSP FIFO.
All in all, I think the usage of the BUFFSTAT register is a good compromise for
all cases, and it is needed for the cases, where the codec also have buffer of
Never the less, we can also add the timestamp based estimation later, but we
need to make sure, that those can be picked somehow for the given setup.
More information about the Alsa-devel