dsound questions

Ove Kaaven ovek at transgaming.com
Mon Feb 28 10:40:38 CST 2005

tor, 24,.02.2005 kl. 22.56 -0600, skrev Jeremy White:
> Case 1:  In the first case, in DSOUND_MixOne, we compute
> a 'probably_valid_to' based on the 'write_pos', which seems quite
> wrong; I believe the logic should be testing whether or not
> there is sufficient data in the mixing buffer, not whether or
> not there is sufficient room in the buffer overall.

The probably_valid_to check is for whether there's likely to be
sufficient data in the *source* streaming buffer to warrant filling the
destination buffer. If the app has only half-filled the streaming
buffer, then it's a better idea to only mix what we know it put there,
and mix the rest of the buffer only after the app has written more stuff
to the buffer, rather than mix everything we can, including invalid
data, then having to backtrack and do a full mix reset when the app
overwrites the invalid data with valid data. The existing code should be

> Then, to my great joy, I found two separate apparent OSS bugs on
> two different systems.  In one, the result of DSP_GETOPTR would
> temporarily 'go backwards' when doing mmaped transfers; in the other,
> my laptop would just stop reading data out of an mmapped buffer,
> for no apparent reason.  Questions:  1) Is there a good set of OSS
> test programs (particularly for mmap) I could/should use to simply validate that
> my system is rational wrt OSS?  2) Are the performance gains from
> DMA mmap really worthwhile?  I wonder if mmap mode is buggy and if we wouldn't
> be better off swtiching to a pure 'write' approach.

In my experience mmap is the only way to get all of good latency, good
precision, minimal sound choppage, reduced CPU usage, and reduced Linux
scheduler issues. But Cedega's wineoss still have mmap disabled by
default since a lot of OSS drivers have bugs. Since ALSA is supposed to
be better, mmap is enabled by default for its winealsa.

More information about the wine-devel mailing list