Re: [PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap

[Peter Ujfalusi <peter.ujfalusi@nokia.com>]

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 
full.
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 
it's own.
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.

-- 
Péter