WINEALSA: comment on unexpected shrinking of mmap-buffer (resend)

[Robert Reif]

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.