wave tests patch
pouech-eric at wanadoo.fr
Sun Aug 15 01:31:58 CDT 2004
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;
> rc=MMDRV_Message(wmld, WODM_GETPOS, (DWORD_PTR)&myTime,
> sizeof(myTime), TRUE);
> if (rc!=TIME_SAMPLES)
> return rc;
> 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 *
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.
More information about the wine-devel