WINEALSA: comment on unexpected shrinking of mmap-buffer (resend)
Alex Villacís Lasso
a_villacis at palosanto.com
Mon Aug 15 11:41:49 CDT 2005
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
More information about the wine-patches
mailing list