[Android] A word on release and audio

[Rafaël Carré]

Le 18/02/2013 14:10, Martin Storsjö a écrit :
> On Fri, 15 Feb 2013, Rafaël Carré wrote:
> 
>> We might have a second bug, because Martin gave me a sample which shows
>> immediate lipsync issue (with OMX enabled).
> 
> I had another look at this now - when this issue happens, I get the 
> following log messages at startup:
> 
> D/VLC     (19217): [0x5f6cd03c]: iomx decoder EmptyThisBuffer 0x5f6cf210, 0x602e5000, 207
> W/VLC     (19217): [0x5f6e2a6c]: main audio output playback too early (-88923): down-sampling
> D/VLC     (19217): [0x5f6cd03c]: iomx decoder FillThisBuffer 0x5f128e88, 0x5eed0000
> D/VLC     (19217): [0x5f6cd03c]: iomx decoder EmptyThisBuffer 0x5f0a4e80, 0x604ba000, 219
> D/VLC     (19217): [0x5f6cd03c]: iomx decoder FillThisBuffer 0x60080228, 0x5ee98000
> D/VLC     (19217): [0x5f6cd03c]: iomx decoder EmptyThisBuffer 0x600800d8, 0x6053b000, 243
> D/VLC     (19217): [0x5f6cd03c]: iomx decoder OmxFillBufferDone 0x60080348, 0x5ee9f000, 4096
> D/VLC     (19217): [0x5f6cd03c]: iomx decoder OmxEmptyBufferDone 0x5f6cf210, 0x602e5000
> D/VLC     (19217): [0x5f6cd03c]: main decoder discarded audio buffer
> D/VLC     (19217): [0x5f6cd03c]: iomx decoder flushing
> 
> Note the "discarded audio buffer" (see src/input/decoder.c) - would this 
> explain the AV sync issues?

"playback too early" means a sync problem has been detected

audio_delay + mdate() - dec_pts == -88.923ms

if we assume audio_delay == 500ms (audio is played 100ms after being
written to opensl library) (The real value might be different but it's a
good guess)

500 + mdate() - dec_pts == -88.923
mdate + 500 = dec_pts - 88.923
dec_pts = mdate - 500 + 88.923
dec_pts = mdate - 412.077

so PTS is 412ms earlier than current time (playback too early)

Then we downsample to reduce the delay without losing audio.


If that fails on the long run and delay keeps getting bigger, we discard
that buffer (condition in src/input/decoder.c +1219 I would guess), and
then we flush completely the audio that was queued ("flushing").

After that, we start filling the audio queue again and we should end up
being synchronized again.


So it indeed shows an issue, but that should be recoverable.

OTOH if that issue can be reproduced, maybe what is causing this
"playback too early" is the real bug.


Just a wild guess: system is too busy running the OMX decoders, and we
can't buffer enough audio during this time?