Re: 2.5.74-mm1

[Daniel Phillips <phillips@arcor.de>]

On Tuesday 08 July 2003 02:29, Davide Libenzi wrote:
> On Tue, 8 Jul 2003, Daniel Phillips wrote:
> > On Tuesday 08 July 2003 00:03, Davide Libenzi wrote:
> > > > > 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.
> > >
> > > That's not fiddling. It is tuning your app so that it won't require
> > > realtime when it is not needed.
> >
> > But realtime is needed, because there is a deadline for each buffer-fill.
>
> Yes, in theory it is needed since you have to meet a deadline. But if
> you program you timings such that your deadline is 400-500ms it is really
> hard to lose it against one of 50-100ms.

1. 400ms buffers are hated by users, as was noted previously.  They are 
passable for some applications, but way too laggy for others.

2. Even if you are will to have a 400-500 ms buffer, if you can prove that you 
will always meet that deadline, then it's a realtime system.

3. If you can show logically that you will nearly always meet the deadline, 
it's a soft realtime system.  That's what we're after here.  From a design 
standpoint, there are elegant soft realtime systems, and there are sucky 
ones.

4. So how do you propose to "program timings" so that it's really hard to miss  
those deadlines?

Regards,

Daniel