opencore a/v sync in eclair

[Andy Quan]

Hi Ravi,

Here are some questions about opencore a/v sync in eclair. We observed 2~3 secs video frame loss at the beginning of playback on some of our platforms. By tracing the code in pvmediaoutput, I find the playback clock goes so quickly at the beginning of playback that videos just can not catch up. It is like that when the 2nd or 3rd video frames arrive at pvmediaoutput, the playback clock has reached 200~300 ms. However the default late margin in eclair is set to be 50ms... I wonder if you can kindly provide any comment or clues on this.

 

2 things I have noticed as well. The 1st is that although player is decoupled from audio system, at the beginning of playback, the alsa buffer is totally empty. Our setting is like 100+ ms buffer size for alsa. And together w/ the track buffer in Android, there might be over 200ms empty buffer at the beginning. Under such circumstances, will opencore keep decoding audio at full speed to fill these kind of buffers so that the playback clock goes too quickly? If so, this means that opencore is probably vulnerable to audio system settings to reach a good a/v sync. How shall I solve this problem?

 

The 2nd thing is that I remember there used to be a driver latency compensation in audio mio, like 90+ms. But since eclair, this compensation is removed from audio mio. I want to know whether previous compensation was expected to solve the 1st problem. If so, why is it removed in eclair?

 

Thanks in advance.

--
Thanks,
Andy

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

[RaviY]

I think all your questions point to the "audio latency". See
inline ...

On May 18, 1:36 am, Andy Quan <androidr...@gmail.com> wrote:
> Hi Ravi,
> Here are some questions about opencore a/v sync in eclair. We observed 2~3
> secs video frame loss at the beginning of playback on some of our platforms.
> By tracing the code in pvmediaoutput, I find the playback clock goes so
> quickly at the beginning of playback that videos just can not catch up. It
> is like that when the 2nd or 3rd video frames arrive at pvmediaoutput, the
> playback clock has reached 200~300 ms. However the default late margin in
> eclair is set to be 50ms... I wonder if you can kindly provide any comment
> or clues on this.

This probably means that the audio driver path was empty, and that the
time to reach for the audio data from the MIO to the actual audio out
is large enough.

>
> 2 things I have noticed as well. The 1st is that although player is
> decoupled from audio system, at the beginning of playback, the alsa buffer
> is totally empty. Our setting is like 100+ ms buffer size for alsa. And
> together w/ the track buffer in Android, there might be over 200ms empty
> buffer at the beginning. Under such circumstances, will opencore keep
> decoding audio at full speed to fill these kind of buffers so that the
> playback clock goes too quickly?

That is correct.

> If so, this means that opencore is probably
> vulnerable to audio system settings to reach a good a/v sync. How shall I
> solve this problem?

"Vulnerable" is not the right word, but yes, a good a/v sync is
dependent on the knowledge of the latency of the audio system. There
is no way for OpenCORE to know what the latency of each and every
platform is. So, it provides a way [at the MIO level] to provide this
latency value. Folks porting the solution have to adjust the latency
value for the corresponding platform.

>
> The 2nd thing is that I remember there used to be a driver latency
> compensation in audio mio, like 90+ms. But since eclair, this compensation
> is removed from audio mio. I want to know whether previous compensation was
> expected to solve the 1st problem. If so, why is it removed in eclair?

Again, this is hardware specific. I don't know of all the changes done
in the platform for the latency adjustment, but they all boil down to
the fact the value changes for hardware.