I Sambhav.
I have this same question regarding the buffering. What I can say is
that I think the reason that the second term is bigger than the first
is because the mFrameCount can be 4 times the size of the driver's
output buffer (or a little bit more). mFrameCount is calculated in
MediaPlayerService.cpp in status_t
MediaPlayerService::AudioOutput::open() this way:
frameCount = (sampleRate*afFrameCount*bufferCount)/afSampleRate;
Where bufferCount is a constant on the media player side (with a value
of 4). I'm also clueless what the buffercount value means or how was
it calculated. So the only variable in the equation seems to be the
clip's sampling rate (as afSampleRate, afFrameCount and afLatency seem
to be constants obtained from the driver).
I hope we can get this doubts resolved.
- Regards.
On Nov 30, 1:54 am, Sambhav <[email protected]> wrote:
> Hi,
>
> Audio Track has a API to query the latency *AudioTrack::latency()*
>
> This latency is calculated with the equation
>
> mLatency = afLatency + (1000*mFrameCount) / sampleRate;
>
> where mFrameCount and sampleRate are parameters given in AudioTrack
> initilzation.
> *afLatency* is the latency obtained from the alsa driver.
> The second part of the equation is significantly a big number.
>
> Does anyone know how AudioFlinger/AudioTrack is adding to the latency ?
> How buffering is done at the framework level before giving it to the drivers
> ?
>
> Regards,
> Sambhav
--
unsubscribe: [email protected]
website: http://groups.google.com/group/android-porting
