DSOUND: buffer underrun & sound chunks left out (RESEND)

[Ove Kaaven]

man, 2003-03-17 kl. 13:15 skrev Jerry Ji:
> 	Actually, it happend when I use winarts, wineoss has already supported 
> IDsDriverBuffer, which works fine.

Well, consider it a bug/problem in winearts, then. If a workaround is
needed (which is possible since any sound server inferior to JACK
usually do not provide too accurate readouts), put that workaround in
that driver, not in dsound.

> As I said, DSOUND_PerformMix and 
> IDirectSoundBufferImpl_GetCurrentPosition use their own code to get the 
> primary play position. I don't know why they don't call 
> DSOUND_PrimaryGetPosition, have they already experienced the same 
> problem?

IDirectSoundBufferImpl_GetCurrentPosition does call
DSOUND_PrimaryGetPosition, when appropriate. Perhaps you missed it.

DSOUND_PerformMix does not call it because PerformMix is a bit
"low-level", and since its purpose is to mix far ahead of the current
play position, it does not need the "lip-sync"-accurate reading that an
application calling GetCurrentPosition might need, hence it neither
needs nor wants the overhead of calling waveOutGetPosition. (While
PerformMix also does trigger notification events, notification events
will almost always be somewhat lagged in any case, even under Windows.)

> > Here's my fix for the problem in WineX, and it's supposed to be able to
> > handle the OFFSETSTOP case. I think it should apply to Wine without too
> > much trouble.
> > 
> 	I'm glad to know you have a better patch. Should wine also accept the 
> patches that accepted by WineX? If I had gotten your patch earlier, 
> maybe I can save some time.

WineX and Wine has mutually incompatible licenses for the moment, so no,
WineX patches can't go into Wine without permission from TransGaming
(which would usually be in the form of a ReWind-compatible patch), and
similarly, Wine patches can't go into WineX without permission from the
patch's author. Because that means WineX can't use the Wine codebase
directly anymore, the TransGaming management has created some employee
guidelines on contribution (and the implicit relicensing) of WineX
patches to Wine, which can be somewhat cynically summarized as "try to
not give anything to Wine that puts us at a competitive disadvantage if
we won't get anything in return for it".

In this case, you'd have done this notification bugfix anyway, so there
wouldn't be any disadvantage for letting you having this WineX patch.
(I think I could have submitted it anyway, but we generally no longer
actively look for things in WineX we could submit to Wine.)