[Bug 33155] New: Broken winmm recording when using an ACM codec

http://bugs.winehq.org/show_bug.cgi?id=33155

Bug #: 33155
           Summary: Broken winmm recording when using an ACM codec
           Product: Wine
           Version: 1.3.25
          Platform: x86
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: winmm&mci
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
    Classification: Unclassified

Extracted from bug #33045, comment #18
wavein recording using the ACM needs rethinking.  Currently, it does anything
from hanging, crashing or recording broken streams.

- WID_PullACMData looks incomplete.  It starts with checking
  device->acm_hdr as if it could persist from a prior invocation,
  however it frees it when returning normally.  Thus it should remain
  local to the function, with device->acm_offs.  In error
  situations, the current code may break, because it may see
  device->acm_hdr.cbDstLength != 0 on entry from a prior
  acmStreamConvert MMSYSERR_* return.

- WID_PullACMData needs better error handling. If acmStreamConvert
  returns an error, the IACaptureClient buffer remains locked, causing
  any subsequent access to error out: recording stalls.

- In WID_PullACMData, the queue->lpNext condition looks bogus in the
  light of IMA_ADPCM's 256 bytes block size.

- More generally, PullACMData needs a redesign.  What to do when
  srcLengthUsed < packet_frames ?!?
  I.e. when the mmdevapi packet length does not match the codec's blocksize,
  e.g. using 10ms packets while IMA_ADPCM likely needs multiples of 256 bytes.
    - We should not throw away recorded bytes given enough buffers.
    - mmdevapi does not accept retrieving less than one packet...
    - mmdevapi does not allow choosing the packet size.

- WID_PullACMData does not yet handle WOM_DONE correctly.  The
  other bug report contains a patch.