winealsa: Separate read and write pointers.

[Joerg-Cyril.Hoehle at t-systems.com]

Hi,

This patch fixes an issue in winealsa's capture mode present since its
inception.  When a client is too slow or does not drain captured data,
new samples do *not* overwrite old ones.  I verified that some time
ago by printing the capture timestamps (that WineXYZ.DRV does not yet
support), as I reported in bug #30147.

Instead, mmdevapi capture allows for the following scenario:
Initialize a 2s buffer, Start, wait 5s, Stop.  Then read 2s worth of
samples from the time when Start was called.  That's exactly like
supplying 2s worth of buffers to winmm.

This patch fixes bug #30147 on the ALSA side. I'll let somebody with OSS4
development headers do the same for wineOSS.

...And we should round capture buffers to multiples of our mmdevapi period
size for simplicity of our code, unless someone provides an explanation
why native is something like 41frames off that limit!


-        buffer = This->local_buffer + This->fmt->nBlockAlign *
-          ((This->lcl_offs_frames + This->held_frames) % This->bufsize_frames);
+        buffer = This->local_buffer + This->wri_offs_frames * This->fmt->nBlockAlign;
Furthermore, this patch eases integration of my lock-less code, which
I'll not release for now, by cleanly separating read and write
pointers during playback and capture.  No more adding of two volatile
entities moving in opposite directions!

Regards,
	Jörg Höhle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-winealsa-Separate-read-and-write-pointers.patch
Type: application/octet-stream
Size: 6250 bytes
Desc: 0004-winealsa-Separate-read-and-write-pointers.patch
URL: <http://www.winehq.org/pipermail/wine-patches/attachments/20121217/cabd9906/attachment-0001.obj>