winepulse test data review

[Joerg-Cyril.Hoehle at t-systems.com]

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