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 correct. > 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.
