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

[Alex Villací­s Lasso]

Robert Reif wrote:

>
> Only the primary buffer supports hardware acceleration.  The secondary
> buffer(s) are implemented in software and mixed into the primary buffer.
> The formats (mono/stereo, 8/16 bit samples, and sample rate) of the
> primary and secondary buffers are totally independent and can be 
> anything.
>
> One of the dsound tests keeps the primary buffer format constant and
> iterates through all secondary buffer formats and another keeps the
> secondary buffer format constant and iterates through all possible
> primary formats.
>
> This is probably what you are seeing.  The secondary buffer format
> has nothing to do with what is sent to the hardware.
>
>
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.

Changelog:
* Re-query buffer capabilities after format change, and display warning 
if buffer size changed after format change. Fixes reference playback 
with ALSA.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: wine-dsound-test-fix.patch
Type: text/x-patch
Size: 4404 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-patches/attachments/20050815/4b72c450/wine-dsound-test-fix.bin