[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