At Wed, 7 Jan 2004 15:54:50 -0500, chmorgan@charter.net 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.