Francois Gouget a écrit :
Francois Gouget wrote: [...]
Anyway, assuming that we need to round up I propose to modify the implementation as in the attached patch. The advantage is that it does not rely on ceil(). In fact it doesn't even use floating point arithmetic so we cannot get any rounding error.
The code that performs TIME_SMPTE calculations is the same for all drivers. It is even the same for the input and output devices (assuming the SMPTE rounding is the same for both) which means it is currently duplicated 12 times.
Would it be better to have waveOutGetPosition() in winmm.c simply query either the TIME_MS from the underlying driver and then perform the conversion? This would be something like:
... if (lpTime->wType==TIME_SMPTE) { LPMMTIME myTime; myTime.wType=TIME_MS; rc=MMDRV_Message(wmld, WODM_GETPOS, (DWORD_PTR)&myTime, sizeof(myTime), TRUE); if (rc!=TIME_SAMPLES) return rc; { ms_to_smpte(myTime.u.ms,lpTime); return TIME_SMPTE; } } return MMDRV_Message(wmld, WODM_GETPOS, (DWORD_PTR)lpTime, uSize, TRUE); }
Then we can move the SMPTE calculation to the ms_to_smpte() helper function in winmm.c. The only drawback is performing SMPTE starting from the TIME_MS data which may have been rounded down a bit. We could eliminate this problem if we had access to the driver's wwo->format data. And then we could also move the TIME_MS calculation to winmm.c and even the TIME_SAMPLES one. Is there any (potential) driver for which this calculation would not work?
lpTime->u.sample = bytes / (wwo->format.wBitsPerSample / 8 * wwo->format.wf.nChannels);
coming back from vacation, and starting browsing thru the pile of e-mail (I'm not sure of the final output of this discussion). How about, letting the drivers decide which format they support (in ???_GETPOS message handling) and have the fallback code in winmm.c ? This would help the factorisation of the code. A+