Hey, On 09/14/2011 05:07 PM, joerg-cyril.hoe...@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/327ce94048dba45c0ed8f727b44aaae6c71a92db..0dc86046e6bec6b0a308c9aab19b8ca4b1c08958:/dlls/mciqtz32/mciqtz.c But I lost track, so I don't know how valid those are still.