Hi,
Maarten Lankhorst kindly posted mmdevapi test results for render and capture gathered using his winepulse driver: http://www.winehq.org/pipermail/wine-devel/2012-October/097602.html
render.c:1199: padding 1250 position 510000/21250 slept 470ms iteration 0
I've run your data through some MS-Excel analysis of mine. Here are my observations.
Exclusive mode tests aren't done, I disabled exclusive mode because I felt tests were insufficient.
It's funny that you say this, because your winepulse driver behaves much like an exclusive mode driver, not a shared mode one ;-)
More specifically,
a) winepulse and exclusive mode do not decrease padding in multiples of the period size.
b) winepulse and exclusive mode appear to equate GetPosition with released frames minus GetCurrentPadding exactly like ALSA hw:0 and dmix do: delay + avail_update = buffer_size (~= 8192 frames)
IOW, the driver pretends that the speaker position is exactly the frame that just fell off the circular buffer. This may be ok for ALSA hw:0 and MS-Windows exclusive mode drivers, but that's wrong for anything with a filter chain in the back.
Hence I assume that winepulse's GetPosition is lying. The question is: does it matter?
If using PA API calls of some sort, you manage to keep the PA-internal latency well below what's the human brain can perceive, I'd say that's ok. Likewise, hw:0 ignores Digital->Analog and wire->LC->speaker times.
Our gripe with PA is precisely that using the regular ALSA->PA path via the ALSA plugin, nobody found a means to keep PA's latency small.
(I'll repeat myself saying that what actually matters is the sum of all latencies and buffers: mmdevapi buffer, PA transformation chain, DAC etc.)
The caveat is that with increasing latency, the behaviour of GCP and GetPosition will differ more and more from native's mixer, until it becomes too much for application X to bear, causing a bug report.
That was about the relationship between GCP and GetPosition. Now what about GetPosition and wall time (as seen by the HighPerformanceTimer)? The largest delta is 8ms, which suggests that your GetPosition is not particularly regular, but as it stays below one 10ms period, it's presumably good enough. By contrast, native's largest delta is < 1ms.
Sometimes up to 2 tests fail due to position updates not being regular,
Indeed, the data reveals it. I guess the reported GetPosition is more related to packet size job completion than actual sample accurate stream position.
I suspect this is because it's nearly done playing though, but it can get worse when you use usb headphones, not much I can do about that though, except if I started lying,
What do you mean with "started lying"? I inferred above that it's already lying.
but it's so far been much simpler when I don't..
The data points look very reasonable -- if audible latency is really low, which the tests cannot reveal.
BTW, I'd really like to see native test results with a USB headphone. IF somebody has such data, pleas show them to me.
I'm not saying that it's bad that winepulse's GetCurrentPadding and GetPosition behave like an exclusive mode driver. After all, winecoreaudio's GCP does the same. Just be aware of the differences.
Your capture results look good.
My favorite capture results (a2dp phone as "microphone"): capture.c:247: Sleep.1 position -1 pad 0 flags abadcafe, amount of frames locked: 0 I love this one because it shows that when you have a source that's not capturing, winepulse still gets the correct results.
This is an area that needs more tests. I've seen native machines behave similarly, OTOH I've read msdn blog entries mentioning that no event is delivered when there's nothing to capture. So the expected behaviour when there's nothing to capture is unclear to me so far.
I'd recommend you simply enable (non-event) exclusive mode, that'll yield twice as many data points per test run. ;-)
BTW, I recommend that you play & increase the worst case test duration to last for 5, 30 or 3000 seconds and see if figures are still regular (e.g. with ALSA->PA, you'd see with 5 seconds that it eats too much data) and whether it still plays without audible glitches.
Regards, Jörg Höhle