Alex Villacís Lasso wrote:
Robert Reif wrote:
Alex Villacís Lasso wrote:
The first test that fails with the ALSA driver is the so-called "reference" tone, which, as far as I could see, is played with a primary buffer, and no secondary buffer. The reference tone uses the hardware position directly, which wraps around at a buffer size that changes unexpectedly when switching playback formats. I have prepared a patch that "fixes" this, by re-querying the buffer size in the case of a primary buffer, and displaying a warning if it detects a buffer size change. However, I don't know if the buffer size is supposed to remain constant across buffer format changes. If it does, then the patch would need to be modified to mark this as a TODO.
Fix the wine ALSA driver rather than the test unless you can prove that the test fails on Windows.
This is a modified patch that marks the problematic buffer resize as a todo_wine. Could somebody please test this patch and confirm that the buffer size actually remains constant across playback format changes?
The problem is that the wine ALSA driver creates a fixed time buffer rather than a fixed size buffer.
Please try your patched test on a real Windows 9X system and on a Windows 2k/xp system. Windows 2k up doesn't really have a hardware primary buffer because of kmixer but a Windows 9X vdx driver will communicate directly with the hardware.
If the test fails on Windows, then we need to change the direct sound implementation to read the new buffer size. Otherwise we need to change the ALSA driver to always create a fixed buffer size regardless of the requested format (like OSS).
We can fix the test and the direct sound dll to work around ALSA's current behavior but that won't help other apps that depend on the primary buffer size not changing if that's what Windows really does.