[MPlayer-users] Regression in version 34853 of mplayer, audio times out
Reimar Döffinger
Reimar.Doeffinger at gmx.de
Sun Apr 15 11:40:20 CEST 2012
On Fri, Apr 13, 2012 at 04:22:42PM -0700, stan wrote:
> On Fri, 13 Apr 2012 19:52:00 +0200
> Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
>
> > On Fri, Apr 13, 2012 at 10:06:37AM -0700, stan wrote:
> > > I'm using version 34853, and it is generating the message
> > > Audio device got stuck!
> > > when playing audio from the command line. It happens
> > > intermittently, anywhere from a few seconds up to a minute. It
> > > never used to do that. I am running Fedora F17, and the version of
> > > mplayer (SVN-r34652) they have packaged does not have this issue.
> >
> > That just doesn't detect the issue.
> > It is printed only when the audio device consumes data far slower than
> > MPlayer expects.
> > It's possible it doesn't quite work reliably with high precision
> > timers, however there's a good chance the latency/playback position
> > reporting by your hardware/driver is imprecise.
> >
> > > if (sleep_time < 10)
> > > sleep_time = 10; // limit to 100
> > > wakeups per second
> >
> > But you could try replacing these two lines with
> > sleep_time += 10;
>
> That decreased the problem, as did replacing the lines with
> if (sleep_time < 10)
> sleep_time = 11; // limit to 100 wakeups per second
>
> If I just hard code the sleep time as
> sleep_time = 12; // limit to 100 wakeups per second
If the += 10 doesn't work that should mean that the audio
hardware/driver has a jitter of > 10 ms when it comes to calculating
the current position.
While "stuck" isn't quite correct, that seems to me like quite bad
behaviour.
More information about the MPlayer-users
mailing list