Hi,
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. 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. Is quartz very decoupled from the underlying audio information? Who stops the clock (if at all) while the stream is paused?
BTW, in theory I have the tools to easily test quartz, using my interactive MCI shell http://bugs.winehq.org/show_bug.cgi?id=20232#c10
However every time I tried, I found mciqtz too underpowered to be able to reasonably use it. :-(
Using the MCI to use mciqtz (which in turn uses quartz.dll) goes as follows: wine wintest.exe mcishell
open foo.wav alias w type mpegvideo status w length play w from 0 notify wait close w # lots of other commands are available
open foo.avi alias a type mpegvideo window a state show status a length play a from 0 close a
Omit the "type mpegvideo" and mciwave or mciavi will be used instead of mciqtz32.dll
Regards, Jörg Höhle
On Wed, Sep 14, 2011 at 9:07 AM, Joerg-Cyril.Hoehle@t-systems.com wrote:
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?.http://msdn.microsoft.com/en-us/library/dd377507%28v=vs.85%29.aspx
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
Hey,
On 09/14/2011 05:07 PM, Joerg-Cyril.Hoehle@t-systems.com wrote:
Hi,
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. 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. Is quartz very decoupled from the underlying audio information? Who stops the clock (if at all) while the stream is paused?
There are 3 different times in quartz which makes it all confusing. However, wine just saves the time when pausing, and subtracts the difference when running again, so for audio clocks it would be a noop, but for wall clocks it's necessary to continue it again without skipping for the amount of time paused.
http://msdn.microsoft.com/en-us/library/dd374626%28v=vs.85%29.aspx
There is also a separate time for seeking, where it corresponds to the time in the file, for example when you seek to 03:10 in a video. This makes it kind of confusing, and wine doesn't handle it completely right in the parsers iirc, but with wineqtdecoder and winegstreamer, that isn't much of an issue. :)
BTW, in theory I have the tools to easily test quartz, using my interactive MCI shell http://bugs.winehq.org/show_bug.cgi?id=20232#c10
However every time I tried, I found mciqtz too underpowered to be able to reasonably use it. :-(
Using the MCI to use mciqtz (which in turn uses quartz.dll) goes as follows: wine wintest.exe mcishell
open foo.wav alias w type mpegvideo status w length play w from 0 notify wait close w # lots of other commands are available
open foo.avi alias a type mpegvideo window a state show status a length play a from 0 close a
Omit the "type mpegvideo" and mciwave or mciavi will be used instead of mciqtz32.dll
I have some mciqtz changes in http://repo.or.cz/w/wine/multimedia.git/blobdiff/327ce94048dba45c0ed8f727b44...
But I lost track, so I don't know how valid those are still.
-
Erich Hoover -
Joerg-Cyril.Hoehle＠t-systems.com -
Maarten Lankhorst