http://bugs.winehq.org/show_bug.cgi?id=33045
--- Comment #21 from Jörg Höhle hoehle@users.sourceforge.net 2013-03-15 19:50:22 CDT ---
- GetPosition returns bogus numbers with ACM codecs
That one is fixed in wine-1.5.26 by commit 2722f2cbfcd5f45a3f53e5b818439fba1de2c14f
The app may work, however there are even more issues involving the ACM. Add to:
What still needs fixing?
- When using the ACM resampler (dlls/msacm32/pcmconverter), rounding in dlls/winmm/waveform.c:WOD_PushData: if(device->orig_fmt->nSamplesPerSec != device->samples_per_sec) device->played_frames += MulDiv(avail_frames, device->orig_fmt->nSamplesPerSec, device->samples_per_sec); causes GetPosition to report byte numbers larger than the sum of WHDR->dwBufferLength! I have no idea how many apps are prepared to handle that :-(
Rounding down may not be a solution, as that may cause the opposite problem: unexpectedly never reach the sum.
I discovered this bug using Wine's PCM resampler. I expect this issue to not only hit the resampler, but all codecs with variable bit rate, likely MP3.
The problem is that instead of sum += acm.cbSrcBytesUsed there's some chunking coming from not being able or wanting to write a full block worth of samples to mmdevapi, so partial sums come into play. Add to that the different frame rates and you've got a rounding issue, much like what happens when adding floating point numbers. Here it would be interesting to find out whether native counts in bytes, target frames or source frames internally, so as to be compatible.
wave.c:1628: testing 4096 bytes then 4096 bytes wave.c:1673: Test failed: after position: 8191 bytes
Apparently w2k does not count in bytes, as there's no explanation for 8191 from 4096+4096 ... except:
The test may not be trustworthy should ADPCM output length depend on the data, because I fed it null bytes, no valid IMA_ADPCM data blocks.
- WID_PullACMData
Ouch, that's enough material for a separate bug report.
Created it. WID_PullACMData or broken ACM recording is bug #33155