Re: Re: winearts patch

> > (4b) wodPlayer_FeedDSP()
> >
> > In the while loop, I could not figure out the purpose of 'availInQ >
> > SPACE_THRESHOLD', so I changed it to 'availInQ'. In reality, the
> > SPACE_THRESHOLD check could probably be left in, I am not sure what
> > the purpose was in the first place.
>
> Dunno either. Reading Chris response, we need this on OSS (because 
> sounds is processed by fragments of fixed size). I don't know how arts 
> behaves here... Thrashing it altogether could also work.

It would seem to reduce the number of calls to arts if we waited for a minimum amount of data, not sure if the input size of each chunk of input data is large enough to make this check pointless or if it won't hurt performace making the additional calls, just wanted to point it out.  The issue with OSS appears to be that for some drivers the fragment prior to the last one isn't played if the last fragment isn't complete, line 1398 of wineoss/audio.c, I'd be inclined to think this isn't something to worry about with arts.

Chris

winearts patch

[Jeremy Shaw]

At Wed, 7 Jan 2004 15:54:50 -0500,
 wrote:
> > > (4b) wodPlayer_FeedDSP()
> > >
> > > In the while loop, I could not figure out the purpose of 'availInQ >
> > > SPACE_THRESHOLD', so I changed it to 'availInQ'. In reality, the
> > > SPACE_THRESHOLD check could probably be left in, I am not sure what
> > > the purpose was in the first place.
> >
> > Dunno either. Reading Chris response, we need this on OSS (because 
> > sounds is processed by fragments of fixed size). I don't know how arts 
> > behaves here... Thrashing it altogether could also work.
>
> It would seem to reduce the number of calls to arts if we waited for a minimum amount of data, not sure if the input size of each chunk of input data is large enough to make this check pointless or if it won't hurt performace making the additional calls, just wanted to point it out.  The issue with OSS appears to be that for some drivers the fragment prior to the last one isn't played if the last fragment isn't complete, line 1398 of wineoss/audio.c, I'd be inclined to think this isn't something to worry about with arts.

Based on that comment in wineoss/audio.c, I would say we don't need to
carry over the SPACE_THRESHOLD check to winearts.

As for performance and the number of calls to winearts, in the patch I
sent there are two cases that can happen:

(1) we run out of wave headers

This should only happen if we are in danger of a buffer underrun. In
this case we probably want to write wave headers as soon as we get
them so the buffer does not get empty.

(2) we run out of space in the arts buffer (but have plenty of wave
    headers left to write)

This is the normal case, in which case we sleep however long it will
take to play BUFFER_REFILL_THRESHOLD packets. This is how we prevent
arts from being overly aggressive at refilling the arts buffer.

Jeremy Shaw.