Well. AudioTrack::latency() doesn't make the audio earlier. The way we
use it makes the audio earlier. Can you study how stagefright uses the
latency() call? I assume Google knows what they are doing.
fxd
On 09/22/2011 08:22 PM, Qiang Luo wrote:
Sheldon,
The GetDelay() counts for the silent priming samples at start. It is
usually around 30ms. Even if I set it to zero, the
AudioTrack::latency() can still make the audio early because of its long
delay value:
AudioTrack::latency() = 138 for on HTC evo
AudioTrack::latency() = 184 for Samsung Nexus S
Qiang
On 9/22/2011 4:49 PM, Sheldon Fu wrote:
That's why we should look into how stagefright player uses the latency()
call properly. There should be no reason we can not use it to get the
correct A/V sync if stagefright can. The renderer pushdown has nothing
to do with this.
From the equation, it seems that the AudioTrack assume that there is at
least one full buffer of delay. I am not sure why it is so but unless we
can prove that this is a bug in AudioTrack, we should trust it.
Are we sure that the 'audio will be a little bit too early' can not be
caused by something else -- e.g. the GetDelay experimental value in the
AAC decoder itself is off?
fxd
On 09/22/2011 06:37 PM, Qiang Luo wrote:
Sheldon,
I can get the latency with m_pAudioSink->latency() which calls
AudioTrack::latency(). The issue here is that a part of the latency is
track dependent, ie:
AudioTrack_latency = audio_flinger_Latency + (1000*mFrameCount) /
sampleRate.
I only care about compensate for the "audio_flinger_Latency" because the
other part is already counted for by the render as pushdown I think. If
I use the entire value of AudioTrack::latency(), the audio will be a
little bit too early.
Qiang
On 9/22/2011 2:51 PM, Sheldon Fu wrote:
I don't think we should call AudioSystem::getOutputLatency() directly.
AudioSystem is a service that should hide beyond the AudioTrack
completely. We should use AudioTrack::latency().
If you need an example of how to use AudioTrack::latency() correctly
(compensating for the addition of frame buffer duration in the latency
calculation e.g), have a look at the stagefright player
(libstagefright/AudioPlayer.cpp). We should closely follow how
stagefright does it for better chance of future compatibility.
fxd
On 09/22/2011 05:26 PM, Qiang Luo wrote:
Overview:
It is well known that there are wide variations in audio system latency
among android devices. In this CR, we query for audio flinger latency
via AudioSystem::getOutputLatency() in the android audio device
initialization function and convert the delay to bytes. We then
compensate for the driver delay in function
CAudioOutAndroid::_GetBytesActualyPlayed(). This takes care of the
device dependent a/v sync issues.
Suggested reviewer: Sheldon
Branches:
380, 310, head
Files modified:
/cvsroot/audio/device/platform/unix/audAndroid.cpp
/cvsroot/audio/device/pub/platform/unix/audAndroid.h
Please review attached diff.
Thanks,
Qiang
.
.
.
.
_______________________________________________
Audio-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/audio-dev
