http://bugs.winehq.org/show_bug.cgi?id=33045
--- Comment #10 from Jörg Höhle hoehle@users.sourceforge.net 2013-03-06 02:50:58 CST --- Is the data sufficient to conclude that: 1. We know nothing yet about w9x (more this week-end). 2. NT-XP machines round down. I can confirm testbot xp results on a real XP machine (though I'd like to see GetPos in bytes, given bug #23079). 3. mmdevapi-era machines (Vista+) handle that situation inconsistently. We lack an explanation for the different results of +1/-1 vs. -1/+1. (w8 results from newtestbot might be interesting too).
I've expressed my opinion often enough. Wine ought to implement sensible behaviour of the APIs at the time they were mostly used. IOW w9x-wxp for winmm.
Also, we shouldn't implement code that may hang (by not sending events). There are enough bug reports of apps that hang, and I find those to be among the most difficult to solve, simply because nobody knows what an app is waiting for.
Given the XP results, I wouldn't try to complete frames with bytes from a previous buffer. MSDN insists on aligned buffers for waveInAddBuffer, so it's doubtful that one should try to complete a buffer-1 with one byte from the next buffer, causing misalignment of all consecutive data. Well, that's a point where audible tests would make a difference (I'd be pleased to throw an audible test at a w95 machine).
So far we only handled PCM data. We don't know how the ACM behaves. Perhaps +1/-1 should work at the ACM level, but rounding down is a must after that has been converted to PCM? (Possibly nonsense, as I'm not sure the ACM codecs would ever return data that doesn't fill a full frame).