I've never tried to understand quartz, but I'd like to know whether quartz
expects particular behaviour from the underlying winmm or mmdevapi
time/position/length functions.
At least for what I've been dealing with so far quartz uses dsound for handling the underlying buffers. So, I would imagine if you've solved the quirks for dsound then you've likely handled quartz as well.
For instance, quartz says its clocks are monotically increasing, whereas no
such requirement is documented (or at least known to me) for the audio stream
positions. This may seem obvious, but then I came across some mailing list where
people reported a sudden backward change in stream position when pluggin/unplugging
earphones or the like.
There are a few different ways to
return time in quartz, but it appears that everything comes down to the reference clock eventually. Have you looked at REFERENCE_TIME and IReferenceClock?.
Is quartz very decoupled from the underlying audio information?
From my exploration it appears to be, but I'm not an expert yet. In the patch you're replying to I just corrected the time conversion between IMediaSeeking (which uses REFERENCE_TIME, LONGLONG measured in 100ns) and IMediaPosition (which uses REFTIME, double measured in seconds). I am trying to look into the time handling further though, as the background music stutters horribly in Fallout 3 (though it works great in Fallout New Vegas).
Who stops the clock (if at all) while the stream is paused?
At least in Wine the reference clock is not stopped when a stream is paused. When pausing the clock is retrieved and stored (MediaControl_Pause) and then on resume it is retrieved again and adjusted to create a new start time (MediaControl_Run). From the reading I've done I don't think there is a way to stop the reference clock, aside from writing and using your own custom clock.
I hope that helps somewhat. I'm not sure exactly what you're trying to do wrt. testing quartz, but if there's some way I can help then please let me know.
Erich Hoover
ehoover@mines.edu