[mythtv-users] Audio glitches on EPG and local commercals

[Jean-Yves Avenard]

On 6 May 2012 16:29, John Morris <jmorris at beau.org> wrote:

> 2012-05-06 01:07:47.683 Player(6): Video is 6.23899 frames behind audio
> (too slow), dropping frame t
> o catch up.
> 2012-05-06 01:07:47.683 AO: Pause 1
> 2012-05-06 01:07:47.692 AO: OutputAudioLoop: audio paused
> 2012-05-06 01:07:47.692 ALSA, Error: WriteAudio: buffer underrun

...

> 2012-05-06 01:07:47.699 Player(6): Video is 4.90727 frames behind audio
> (too slow), dropping frame to catch up.
> 2012-05-06 01:07:47.699 Player(6): Video is 3.95019 frames behind audio
> (too slow), dropping frame to catch up.
> 2012-05-06 01:07:47.699 Player(6): Waiting for video buffers...
> 2012-05-06 01:07:47.699 AO: Pause 1
> 2012-05-06 01:07:47.730 AO: Pause 0
> 2012-05-06 01:07:47.730 AO: Pause 0
> 2012-05-06 01:07:47.781 IsTunable(2810)
> 2012-05-06 01:07:47.786 AO: OutputAudioLoop: Play Event
> 2012-05-06 01:07:47.787 IsTunable(2810) -> true

Well there you go.

video is decoding to slowly and the gap between audio and video
becomes too great and audio needs to be paused for video decoding to
catch up.


>
> It is complaining of underruns but I already did the bit to increase the
> buffer with:

the underruns are not due to buffering here, but because the audio
card is starved

basically, your system is too slow

>
> # cat /proc/asound/card1/pcm3p/sub0/prealloc
> 320
>
> The obvious problem is figuring out just what the heck sort of resource
> starvation could be happening on this machine, it is more than enough
> for the job.  Painting the guide isn't exactly hard.  But the larger
> problem is that it looks like a case where it isn't making an optimal
> decision in dealing with the first problem.  A media player should keep
> the audio streaming at all cost and with realtime priority it is hard to
> imagine that not being possible.  Cutting audio frames is almost as bad
> but preferred to switching off the transmitter, especially on
> multi-channel audio.  Dropping video frames is almost always the right
> decision over breaking the audio.

I would agree with you, except that there's currently only one player,
and audio and video are in sync and comes together.

You can't always continue decoding the audio, without also decoding the video.

If you read the logs, you will see that it does drop video frames
first, but it comes to a point where it's not recoverable.

But thank you for your insightful analysis, and we'll welcome your
future contributions to make things better