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

[Robert Reif]

Alex Villací­s Lasso wrote:

> Alex Villací­s Lasso wrote:
>
>>
>>> The good news: the patch sort of works (in my setup, at least, with 
>>> Fedora Core 4). All the games I have (Japanese RPGs) now have smooth 
>>> sound, unless the CPU load is too high.
>>> The bad news: the patch does nothing to make the dsound tests pass 
>>> in Wine (but they were already failing before the patch :-)
>>
>>
>>
>> In a previous post, I commented about DirectSound tests failing when 
>> ALSA is used with full hardware acceleration. Now I know the reason why.
>>
>> As far as I can glean from the code, DirectSound is supposed to 
>> report the application several properties of the sound system, 
>> including the size of the hardware buffer. This hardware buffer is 
>> queried by the snd_hw_params_get_buffer_size(), and is then converted 
>> from frame units to bytes. Then the application, or in this case, the 
>> test, expects the buffer size to remain constant for each and every 
>> hardware buffer created, regardless of requested format. Only this 
>> assertion fails in ALSA. For example, the capability query causes the 
>> following output to be shown:
>>
>> trace:wave:DSDB_CreateMMAP format=U8  frames=11025  channels=2  
>> bits_per_sample=8  bits_per_frame=16
>> trace:wave:DSDB_CreateMMAP created mmap buffer of 11025 frames (22050 
>> bytes) at 0x7c0fd100
>>
>> This reported size (22050 bytes) remains constant as long as the 
>> request is for U8 format with 2 channels (although the mmap address 
>> jumps between three different values in my setup; this may or may not 
>> be relevant). However, as soon as the requested format changes, the 
>> trace shows the following:
>>
>> trace:wave:DSDB_CreateMMAP format=S16_LE  frames=3763  channels=2  
>> bits_per_sample=16  bits_per_frame=32
>> trace:wave:DSDB_CreateMMAP created mmap buffer of 3763 frames (15052 
>> bytes) at 0x7c0fd6b8
>>
>> There goes a fourth mmap address, but the truly interesting thing is 
>> that the buffer size also changes, and no longer matches the 
>> previously reported size of 22050 bytes. The test then goes and plays 
>> a 5-second sound with the (now incorrect) buffer size of 22050 bytes, 
>> not noting that the reported position is wrapping around at 15052 bytes:
>>
>> ds3d.c:431:    Playing 5 second 440Hz tone at 11025x16x2
>>
>> ...
>>
>> trace:dsound:DSOUND_PrimaryGetPosition (0x7fe03ab8,0x7fa6fa80,(nil))
>> trace:wave:IDsDriverBufferImpl_GetPosition hw_ptr=0x00000000, 
>> playpos=0, writepos=-1, mmap_buflen_bytes=15052
>> trace:dsound:DSOUND_PrimaryGetPosition playpos = 0, writepos = 0 
>> (0x7fe03ab8, time=1913)
>> trace:dsound:PrimaryBufferImpl_GetCurrentPosition playpos = 0, 
>> writepos = 0 (0x7fe03ab8, time=1913)
>> ds3d.c:230:buf size=22050 last_play_pos=0 play_pos=0 played=0 / 
>> 220500, fraction_played=0
>> ds3d.c:248:offset=15052 free=6998 written=15052 / 220500
>>
>> ...
>> ds3d.c:230:buf size=22050 last_play_pos=10296 play_pos=11700 
>> played=11700 / 220500, fraction_played=1404
>> ds3d.c:248:offset=10296 free=1404 written=32346 / 220500
>> ds3d.c:230:buf size=22050 last_play_pos=11700 play_pos=13104 
>> played=13104 / 220500, fraction_played=1404
>> ds3d.c:248:offset=11700 free=1404 written=33750 / 220500
>> ds3d.c:230:buf size=22050 last_play_pos=13104 play_pos=14508 
>> played=14508 / 220500, fraction_played=1404
>> ds3d.c:248:offset=13104 free=1404 written=35154 / 220500
>> ds3d.c:230:buf size=22050 last_play_pos=14508 play_pos=860 
>> played=22910 / 220500, fraction_played=8402
>> ds3d.c:248:offset=14508 free=8402 written=36558 / 220500
>>
>> Please note that the play_pos wrapped from 14508 to 860 because it 
>> exceeded 15052 bytes, but the test assumes it wrapped around at 22050 
>> bytes, so it miscalculates the fraction_played, advancing it at an 
>> abnormally fast rate. That is how the following result ensues:
>>
>> trace:dsound:DSOUND_PrimaryGetPosition playpos = 176, writepos = 0 
>> (0x7fe03ab8, time=5366)
>> trace:dsound:PrimaryBufferImpl_GetCurrentPosition playpos = 176, 
>> writepos = 0 (0x7fe03ab8, time=5366)
>> ds3d.c:230:buf size=22050 last_play_pos=13824 play_pos=176 
>> played=220676 / 220500, fraction_played=8402
>> ds3d.c:237:all the samples have been played, stopping...
>> ds3d.c:279:stopping playback
>> trace:dsound:PrimaryBufferImpl_Stop (0x7fe143b8)
>> ds3d.c:628: Test failed: The sound played for 3453 ms instead of 5000 ms
>>
>> Many other tests with formats other than U8, 11025Hz fail for the 
>> same reason. Any other DirectSound application that reuses the buffer 
>> size as the test does will fail in the same way (music mixing up and 
>> prematurely stopping). However, I am to understand that this test 
>> passes on Windows, in all versions.
>>
>> Now that I have found the issue, I ask for help in suggesting a 
>> proper fix. I think that the ALSA implementation used to have a 
>> separate buffer from which samples were copied into the hardware 
>> buffer, but this implementation was scrapped for some reason (and I 
>> think, without re-running the ALSA tests). So I tried using 
>> snd_hw_params_set_buffer_size() - it fails to set the buffer size to 
>> the previously reported size. So I am still thinking about this. Any 
>> comments or suggestions for fixing this will be greatly appreciated.
>>
>> BTW, does the DirectSound API allow the application to access the 
>> hardware mmap directly (that is, not just by specifying the buffer to 
>> be played)? If not, one possible solution would be to remember the 
>> first reported buffer size, and wrap the *reported* position around 
>> at that buffer size, even when the ALSA playback uses the real buffer 
>> size. However, when I tried to do this (by hardcoding 22050 as a 
>> wraparound value, just as a test), Wine promptly crashed, so I need 
>> more insight into this.
>>
>> Alex Villacís Lasso
>>
> Resending because previous attempt probably was rejected due to 
> gigantic attachment (my bad).

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.