On Monday 07 July 2003 20:36, Davide Libenzi wrote:
> On Mon, 7 Jul 2003, Daniel Phillips wrote:
> > On Monday 07 July 2003 19:25, Davide Libenzi wrote:
> > > Jamie, looking at those reports it seems it is not only a sound players
> > > problem.
> >
> > You still seem to be having trouble with the idea that the sound
> > servicing thread is a realtime process, and thus fundamentally different
> > from other kinds of processes. Could you please explain why you disagree
> > with this?
>
> I'm just trying to figure out why :
>
> 1) RealPlayer does not skip on my 2.4.20
^^^^^^
We're talking about 2.5.
> 2) RealPlayer does not skip on my office XP
> 3) MediaPlayer does not skip on my office XP
>
> Maybe it is more of an application problem.
Partly. We've been through that in pretty good detail. There are
combinations of hardware and kernel versions that happen to be pretty good at
running sound, that doesn't mean the problem is dealt with so that corner
cases don't come up. A 99% solution is not good enough, that still will
leave 10,000's of Linux users with poor sound performance.
Zinf does things correctly: it has a big buffer and it tries to set an
elevated priority for its sound servicing thread. With 2.5, that isn't
enough, and Con's tweaking isn't enough. And that's not wrong, because the
kernel *should not* try to identify realtime threads automagically.
Zinf could go further and try to set a posix realtime scheduling mode, but
that attempt would be blocked by the root requirement for realtime
scheduling, which is ihmo due to braindamage in the definition of the posix
realtime scheduling modes. This last we *can* fix in the kernel, by creating
a new realtime scheduling mode that is sane enough to be used by normal
users. Then sound applications would need to be changed to use it, which
really is no big deal.
In the meantime, a combination of Con's priority tweaks and user-initiated
nice works well.
> > > The *application* has to hint the scheduler, not the user.
> >
> > Partly true, in that users should be able to supply the hint in some way,
> > they desire. However in this case - Zinf - the point is moot, because
> > Zinf is trying hard to give the hint, but it fails because of
> > above-mentioned braindamage.
>
> Try to play with SNDCTL_DSP_SETFRAGMENT. Last time I checked the kernel
> let you set a dma buf for 0.5 up to 1 sec of play (upper limited by 64Kb).
> Feeding the sound card with 4Kb writes will make you skip after about 50ms
> CPU blackout at 44KHz 16 bit. RealPlayer uses 16Kb feeding chunks that
> makes it able to sustain up to 200ms of blackout.
That's just fiddling, it doesn't deal with the basic problem. Anyway, big
buffers have their own annoyances. Have you tried the graphic equalizer in
xmms lately? A one second lag on slider adjustment is not nice.
Regards,
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:30 EST