Nevermind, the *4 factor messes up other tests. I guess the real driver latency should not be hacked.
On Nov 11, 11:11 am, RockNCode <[email protected]> wrote: > HI. > > I'm currently working on anAVsyncissue seen on froyo, seen mainly > with low audio sampling rates. Basically, I'm seeing that the video is > about 300 ms ahead of the audio. Now I've narrowed down the issue to > this formula in AudioTrack.cpp > > mLatencyUs= afLatency + frameCount*1000/sampleRate. > > mLatencyUs is used to calculate the realTimeClock, used by the avsync > algorithm in the Awesome player. > > The afLatency is the audio latency reported by our audio HAL. For our > case it is reporting 92.8 ms (4096 buffer, 44100 sampling rate). The > second term of this formula is always giving me 371.5-372, which is 4 > times the latency reported by the audio HAL. By doing experiments, > I've found that multiplying afLatency by 4 at audio HAL level (so > mLatency would be 372 + 372), is giving me goodavsync. > > does it makes sense to anyone what I'm doing ? > is mLatency just used foravsync? > Could I have other bad consequences to increase the afLatency value ? > So far I haven't seen any. > > Thanks. -- unsubscribe: [email protected] website: http://groups.google.com/group/android-porting
