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: wine-bugs(a)winehq.org ReportedBy: hoehle(a)users.sourceforge.net 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.