From: Lee Revell <rlrevell@joe-job.com>
To: Denis Vlasenko <vda.linux@googlemail.com>
Cc: Jan Engelhardt <jengelh@linux01.gwdg.de>,
Eric Piel <Eric.Piel@tremplin-utc.net>,
mplayer-users@mplayerhq.hu, linux-kernel@vger.kernel.org
Subject: Re: mplayer + heavy io: why ionice doesn't help?
Date: Sun, 20 Aug 2006 17:36:07 -0400 [thread overview]
Message-ID: <1156109768.10565.55.camel@mindpipe> (raw)
In-Reply-To: <200608201843.58849.vda.linux@googlemail.com>
On Sun, 2006-08-20 at 18:43 +0200, Denis Vlasenko wrote:
> On Sunday 20 August 2006 16:43, Lee Revell wrote:
> > On Sun, 2006-08-20 at 10:22 +0200, Jan Engelhardt wrote:
> > > >
> > > >It helps. mplayer skips much less, but still some skipping is present.
> > >
> > > Try with -ao alsa, then it should skip less, or at least, if it skip, skip
> > > back so that less audio is lost.
> > > When playing audio-only files, it is always wise to specify e.g. -cache 320
> > > which proved to be a good value for my workloads.
> > >
> >
> > Only with the very latest versions of mplayer does ALSA work at all.
> > It's unusable here because it resets the auduio stream on each underrun
> > rather than simply ignoring them.
>
> I'm not sure that I ever got an underrun (may check it
> for you if you need that, how to do it?),
> but mplayer -ao alsa is working for me just fine.
>
You probably don't get underruns because your machine is fast. Mine is
a 600Mhz Via board, but I know this is an mplayer ALSA driver bug
because it works perfectly with -ao oss, and because mplayer's ALSA
driver maintainer has acknowledged the bug.
> I eliminated skips due to CPU and disk using
> nice and -cache 8000. I still can make it skip
> when my KDE background picture is changing.
>
I also must run mplayer at nice -20 for it to be usable.
> I think that these skips are caused by the X server.
> It has no prioritization for request handling and
> thus it does not paint mplayer output fast enough:
> it needs to repaint background and semi-transparent
> konsole(s), and that is taking a few seconds at least.
>
> This is probably aggravated by serializing nature of Xlib,
> according to:
>
> http://en.wikipedia.org/wiki/XLib
> http://en.wikipedia.org/wiki/XCB
I think the problem is also due to mplayer's faulty design. It should
be multithreaded and use RT threads for the time sensitive work, like
all professional AV applications and many other consumer players do.
Lee
next prev parent reply other threads:[~2006-08-20 21:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-18 17:37 mplayer + heavy io: why ionice doesn't help? Denis Vlasenko
2006-08-18 17:57 ` Nick Warne
2006-08-18 18:01 ` Eric Piel
2006-08-19 18:04 ` Denis Vlasenko
2006-08-20 8:22 ` Jan Engelhardt
2006-08-20 14:43 ` Lee Revell
2006-08-20 16:43 ` Denis Vlasenko
2006-08-20 21:36 ` Lee Revell [this message]
2006-08-20 22:04 ` Jan Engelhardt
2006-08-22 16:26 ` Denis Vlasenko
2006-08-22 17:37 ` Jan Engelhardt
2006-08-22 17:38 ` Xavier Bestel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1156109768.10565.55.camel@mindpipe \
--to=rlrevell@joe-job.com \
--cc=Eric.Piel@tremplin-utc.net \
--cc=jengelh@linux01.gwdg.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mplayer-users@mplayerhq.hu \
--cc=vda.linux@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox