26 Oct
2012
26 Oct
'12
12:53 p.m.
Added wine-devel to cc
Op 26-10-12 13:12, Joerg-Cyril.Hoehle(a)t-systems.com schreef:
Maarten,
I'll try and come up with a review of your winepulse patches yet I'm not familiar
with the PA API.
Regarding your dsound ones, I'm sorry I've not enough experience
with the DSound API to be really useful. I was happy that Alexey Loukianov and A.Eikum
worked on DSound.
One issue that struck me is the 5ms period downgrade in winepulse.
I advise you keep that as a separate patch. Halving the externally visible SetEVentHandle
rate
is certainly not something that should be in the one big core patch introducing
winepulse.
Yeah this was explicitly to make skyrim work better, I return the updated latency in
GetStreamLatency, and with the fixes wine dsound uses that value for calculating mixing
fraglen.
Even if it causes no test failure, that trick would
certainly be visible in the log lines. Native shows:
render.c:2084: Should play 1000ms continuous tone with fragment size 480.
render.c:2136: Released 48000=100x480 -960 frames at 48000 worth 980ms in 1008ms
Yeah I seem to fire more events, so less data gets played.
This requires some rethinking though, winepulse doesn't
attempt to hide latency at all, and so far the mmdevapi tests have failed on my usb
headphones because it didn't always have a smooth buffer increment.
The tests don't fail, but because of the extra firing processing sometimes gets
skipped..
Woops, some more digging revealed I also seemed to have done a SetEvent in
pulse_started_callback, which is entirely bogus, presumably a leftover from
before I hooked up the latency callback for when in underrun mode.
With that SetEvent part of the latency hack disabled and the bogus SetEvent removed,
I get:
render.c:2127: Released 44541=101x441 -441 frames at 44100 worth 1000ms in 1003ms
Can't get better than that. :-)
I disabled the exclusive mode on winepulse because I felt that mode was sufficiently
different in behavior, and I don't think the mmdevapi tests cover it properly.
I'll do some more digging if the SetEvent is still needed for the hack, or if
the period lowering is enough. I would suspect lowering the period is sufficient
now. Quick testing of skyrim seems to indicate I can leave the SetEvent part out,
so I pass all tests properly again. :-)
BTW, I'd still be pleased if you could upload
somewhere to bugzilla results from
runtest -v -i mmdevapi/render and capture
from your winepulse driver. I think I asked you that favour already but found nothing.
My tree removes todo_wine from the tests, but anyway:
capture.c:501: Returned periods: 10.0000 ms 0.4988 ms
capture.c:513: pwfx: 0xdccb0
capture.c:514: Tag: fffe
capture.c:515: bits: 32
capture.c:516: chan: 2
capture.c:517: rate: 44100
capture.c:518: align: 8
capture.c:519: extra: 22
capture.c:524: Res: 32
capture.c:525: Mask: 3
capture.c:526: Alg: FLOAT
capture.c:585: Returned latency: 10.0000 ms
capture.c:185: Wait'ed position 0 pad 0 flags 0, amount of frames locked: 441
capture.c:247: Sleep.1 position 441 pad 15435 flags 0, amount of frames locked: 441
capture.c:291: GetBufferSize 22050 period size 441
capture.c:301: Overrun position 1323 pad 22050 flags 1, amount of frames locked: 441
capture.c:328: Cont'ed position 1764 pad 21609 flags 0, amount of frames locked: 441
capture.c:352: Restart position 2205 pad 21168 flags 0, amount of frames locked: 441
capture.c:383: Reset position -1 pad 0 flags abadcafe, amount of frames locked: 0
capture.c:409: Running position 23373 pad 7938 flags 0, amount of frames locked: 441
capture: 255 tests executed (0 marked as todo, 0 failures), 0 skipped.
render.c:185: Returned periods: 10.0000 ms 2.0000 ms
render.c:197: pwfx: 0xdccb0
render.c:198: Tag: fffe
render.c:199: bits: 32
render.c:200: chan: 6
render.c:201: rate: 48000
render.c:202: align: 24
render.c:203: extra: 22
render.c:208: Res: 32
render.c:209: Mask: 3f
render.c:210: Alg: FLOAT
render.c:268: Initialize(duration=0) GetBufferSize is 192
render.c:333: Returned latency: 10.0000 ms
render.c:411: IsSupported(shared , 8000x 8x1)
render.c:411: IsSupported(shared , 8000x 8x2)
render.c:411: IsSupported(shared , 8000x16x1)
render.c:411: IsSupported(shared , 8000x16x2)
render.c:411: IsSupported(shared , 11025x 8x1)
render.c:411: IsSupported(shared , 11025x 8x2)
render.c:411: IsSupported(shared , 11025x16x1)
render.c:411: IsSupported(shared , 11025x16x2)
render.c:411: IsSupported(shared , 12000x 8x1)
render.c:411: IsSupported(shared , 12000x 8x2)
render.c:411: IsSupported(shared , 12000x16x1)
render.c:411: IsSupported(shared , 12000x16x2)
render.c:411: IsSupported(shared , 16000x 8x1)
render.c:411: IsSupported(shared , 16000x 8x2)
render.c:411: IsSupported(shared , 16000x16x1)
render.c:411: IsSupported(shared , 16000x16x2)
render.c:411: IsSupported(shared , 22050x 8x1)
render.c:411: IsSupported(shared , 22050x 8x2)
render.c:411: IsSupported(shared , 22050x16x1)
render.c:411: IsSupported(shared , 22050x16x2)
render.c:411: IsSupported(shared , 44100x 8x1)
render.c:411: IsSupported(shared , 44100x 8x2)
render.c:411: IsSupported(shared , 44100x16x1)
render.c:411: IsSupported(shared , 44100x16x2)
render.c:411: IsSupported(shared , 48000x 8x1)
render.c:411: IsSupported(shared , 48000x 8x2)
render.c:411: IsSupported(shared , 48000x16x1)
render.c:411: IsSupported(shared , 48000x16x2)
render.c:411: IsSupported(shared , 96000x 8x1)
render.c:411: IsSupported(shared , 96000x 8x2)
render.c:411: IsSupported(shared , 96000x16x1)
render.c:411: IsSupported(shared , 96000x16x2)
render.c:2174: Output to a MS-DOS console is particularly slow and disturbs timing.
render.c:2175: Please redirect output to a file.
render.c:870: Testing shared mode
render.c:902: Latency: 10.0000 ms
render.c:921: BufferSize 24000 estimated fragment 480 x 50 = 24000
render.c:945: Clock Frequency 1152000
render.c:974: data at 0x530030
render.c:1023: padding 14302 past sleep #2
render.c:1042: padding 14302 position 232752 past stop #2
render.c:1076: data at 0x530030
render.c:1100: position 115416 past 100ms sleep #3
render.c:1117: padding 18711 position 126936 past stop #3
render.c:1145: data at 0x530030 for prefill 22500
render.c:1175: hpctime 381 after 370ms
render.c:1194: hpctime 481 pcpos 492
render.c:1199: padding 1250 position 510000/21250 slept 470ms iteration 0
render.c:1227: data at 0x530030
render.c:1194: hpctime 589 pcpos 599
render.c:1199: padding 18551 position 634776/26449 slept 570ms iteration 1
render.c:1232: data at 0x530030 (small 5449)
render.c:1194: hpctime 691 pcpos 701
render.c:1199: padding 19321 position 747072/31128 slept 670ms iteration 2
render.c:1232: data at 0x530030 (small 4679)
render.c:1194: hpctime 793 pcpos 803
render.c:1199: padding 18727 position 873624/36401 slept 770ms iteration 3
render.c:1232: data at 0x530030 (small 5273)
render.c:1194: hpctime 895 pcpos 905
render.c:1199: padding 19089 position 991488/41312 slept 870ms iteration 4
render.c:1232: data at 0x530030 (small 4911)
render.c:1194: hpctime 996 pcpos 1007
render.c:1199: padding 19279 position 1104792/46033 slept 970ms iteration 5
render.c:1232: data at 0x530030 (small 4721)
render.c:1194: hpctime 1098 pcpos 1109
render.c:1199: padding 18961 position 1225728/51072 slept 1070ms iteration 6
render.c:1232: data at 0x530030 (small 5039)
render.c:1194: hpctime 1200 pcpos 1211
render.c:1199: padding 19326 position 1337904/55746 slept 1170ms iteration 7
render.c:1232: data at 0x530030 (small 4674)
render.c:1194: hpctime 1302 pcpos 1312
render.c:1199: padding 18970 position 1458624/60776 slept 1270ms iteration 8
render.c:1232: data at 0x530030 (small 5030)
render.c:1248: position 1458624
render.c:1257: position 2034624 past underrun, 0 padding left, 84776 frames written
render.c:1279: hpctime 2304 after underrun
render.c:882: Testing exclusive mode at 48000
render.c:2075: Should play 1000ms continuous tone with fragment size 480.
render.c:2127: Released 48480=101x480 -480 frames at 48000 worth 1000ms in 1002ms
render.c:2075: Should play 1000ms continuous tone with fragment size 480.
render.c:2127: Released 48480=101x480 -480 frames at 48000 worth 1000ms in 1004ms
render.c:2075: Should play 1000ms continuous tone with fragment size 480.
render.c:2127: Released 48480=101x480 -960 frames at 48000 worth 990ms in 1003ms
render.c:2075: Should play 1000ms continuous tone with fragment size 480.
render.c:2127: Released 48480=101x480 -480 frames at 48000 worth 1000ms in 1007ms
render.c:2075: Should play 1000ms continuous tone with fragment size 480.
render.c:2127: Released 48480=101x480 -480 frames at 48000 worth 1000ms in 1002ms
render.c:2075: Should play 1000ms continuous tone with fragment size 480.
render.c:2127: Released 48480=101x480 -480 frames at 48000 worth 1000ms in 1005ms
render.c:2075: Should play 1000ms continuous tone with fragment size 480.
render.c:2127: Released 48480=101x480 -960 frames at 48000 worth 990ms in 997ms
render.c:2075: Should play 1000ms continuous tone with fragment size 480.
render.c:2127: Released 48480=101x480 -960 frames at 48000 worth 990ms in 999ms
render.c:2075: Should play 1000ms continuous tone with fragment size 480.
render.c:2127: Released 48480=101x480 -330 frames at 48000 worth 1003ms in 1009ms
render.c:2075: Should play 1000ms continuous tone with fragment size 480.
render.c:2127: Released 48480=101x480 -960 frames at 48000 worth 990ms in 1003ms
render: 4996 tests executed (0 marked as todo, 0 failures), 0 skipped.
Sometimes up to 2 tests fail due to position updates not being regular, as you can
see from this line:
render.c:2127: Released 48480=101x480 -330 frames at 48000 worth 1003ms in 1009ms
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, but it's so far been much simpler when I don't..
Exclusive mode tests aren't done, I disabled exclusive mode because I felt tests
were insufficient. If you can point me to an application using it I'll work on it
though, but I didn't feel mmdevapi tests were complete enough for handling this.
*BONUS*
My favorite capture results (a2dp phone as "microphone"):
capture.c:501: Returned periods: 135.2834 ms 135.2834 ms
capture.c:513: pwfx: 0xdccb0
capture.c:514: Tag: fffe
capture.c:515: bits: 32
capture.c:516: chan: 2
capture.c:517: rate: 44100
capture.c:518: align: 8
capture.c:519: extra: 22
capture.c:524: Res: 32
capture.c:525: Mask: 3
capture.c:526: Alg: FLOAT
capture.c:585: Returned latency: 135.2834 ms
capture.c:168: Test failed: Waiting on event handle failed!
capture.c:185: Wait'ed position -1 pad 0 flags abadcafe, amount of frames locked: 0
capture.c:217: Test failed: GetNextPacketSize 0 vs. GCP 0
capture.c:220: Test failed: Valid IAudioCaptureClient_GetBuffer returns 08890001
capture.c:247: Sleep.1 position -1 pad 0 flags abadcafe, amount of frames locked: 0
capture.c:286: Test failed: GetNextPacketSize 0 vs. GetDevicePeriod 5966
capture.c:291: GetBufferSize 23864 period size 5966
capture.c:299: Test failed: Valid IAudioCaptureClient_GetBuffer returns 08890001
capture.c:301: Overrun position -1 pad 0 flags abadcafe, amount of frames locked: 0
capture.c:326: Test failed: Valid IAudioCaptureClient_GetBuffer returns 08890001
capture.c:328: Cont'ed position -1 pad 0 flags abadcafe, amount of frames locked: 0
capture.c:347: Test failed: Valid IAudioCaptureClient_GetBuffer returns 08890001
capture.c:352: Restart position -559038737 pad 0 flags abadcafe, amount of frames locked:
0
capture.c:354: Test failed: restarted GCP 0
capture.c:383: Reset position -1 pad 0 flags abadcafe, amount of frames locked: 0
capture.c:408: Test failed: Valid IAudioCaptureClient_GetBuffer returns 08890001
capture.c:409: Running position -1 pad 0 flags abadcafe, amount of frames locked: 0
capture.c:426: Test failed: Wait(event) after Stop gave 102
capture.c:434: Test failed: Wait(event) after Reset gave 102
capture.c:440: Test failed: Wait(NULL event) gave 102
capture: 224 tests executed (0 marked as todo, 12 failures), 0 skipped.
I love this one because it shows that when you have a source that's not
capturing, winepulse still gets the correct results. Even though obviously the
tests completely fail because there's no data. ;-)
~Maarten
3 Dec
3 Dec
2:42 p.m.
New subject: winepulse test data review
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
10:29 p.m.
New subject: winepulse test data review
Op 03-12-12 15:42, Joerg-Cyril.Hoehle(a)t-systems.com schreef:
Not directly passing the value in GetCurrentPadding
through as was reported by
pulseaudio, but hide the irregular pointner advancements. I prefer to just report the
values from pulseaudio directly.
Unless I'm mistaken, because
I use early requests, pulseaudio will only have 1 more
period internally than the buffer length of my sound buffer, so if the buffer is 30 ms,
period is 10 ms, and I only fill it with 10 ms data, max latency would be 20 ms at that
point.
If you say jitter is 8 ms (which I find very high), you wouldn't notice that extra 10
ms..
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
It typically will keep it in multiples if pulseaudio is run
in timer driven mode (glitchfree audio),
however if you create a buffer that's 2x period size or less it seems to be more
aggressive with
updates.
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?
Well from how I understand with winepulse
pulseaudio will only add 1 more period on top of that.
I do or did have code for IAudioClock::GetPosition, winepulse v18 commit removed it
entirely.
I could reinstate it, but I didn't find the mmdevapi tests strict enough to justify
it.
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.
Delta
shouldn't be so high, are you using the timestamps from IAudioClock2::GetPosition ?
Those are lies, I could probably fix that by recording them in pulse_wr_callback. But you
could try testing with my tree, I enable rtkit in there which should decrease jitter
regardless.
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.
I guessed
that it just has a bunch of packets that are re-used, like the way I'm
implementing capture in winepulse. See ACPacket, it's stuffed in locked_ptr,
empty ones in packet_free_head, and filled in packet_filled_head.
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.
render.c:2290: Released
441441=1001x441 -441 frames at 44100 worth 10000ms in 9972ms
render.c:2290: Released 4410441=10001x441 -441 frames at 44100 worth 100000ms in 99900ms
Some interruption of the audio stream, that sleep(i % 10) is suspect... what are you
really testing there?
And that test seems to be sensitive to not being run in realtime,
it seems to work slightly better if I change that to if I set
THREAD_PRIORITY_TIME_CRITICAL on the thread,
Sleep(0) (for i%10 = 0) looks kind of wrong though
Oops and another bugfix[1], pulse_wr_callback can sometimes be called with no update,
which can be a
contributing factor why sometimes the tests finished early..
with that fixed and no sleep:
render.c:2296: Released 4410441=10001x441 -441 frames at 44100 worth 100000ms in 99998ms
And with rt prio set, and sleep:
render.c:2291: Released 4410441=10001x441 -882 frames at 44100 worth 99990ms in 100014ms
I may also be hitting some pulseaudio bug though, if I play some music on the background
when one
of those tests start the sound during the test works ok, even if I pause it after that.
Come to think of it, what is more likely is that on underrun the device is paused since
nothing else is
playing, and it starts again when being fed again, that would explain why I'm getting
interruptions
like the +14 ms above..
Also played skyrim for a few hours just fine, it wanted a 20 ms buffer for some reason..
Still not sure why, but who am I to object..
~Maarten
[1] winepulse don't SetEvent on no pad change..
diff --git a/dlls/winepulse.drv/mmdevdrv.c b/dlls/winepulse.drv/mmdevdrv.c
index 554a9fc..a4575d5 100644
--- a/dlls/winepulse.drv/mmdevdrv.c
+++ b/dlls/winepulse.drv/mmdevdrv.c
@@ -531,7 +531,10 @@ static void pulse_wr_callback(pa_stream *s, size_t bytes, void
*userdata)
else
This->pad = 0;
- assert(oldpad >= This->pad);
+ if (oldpad == This->pad)
+ return;
+
+ assert(oldpad > This->pad);
This->clock_written += oldpad - This->pad;
TRACE("New pad: %zu (-%zu)\n", This->pad /
pa_frame_size(&This->ss), (oldpad - This->pad) /
pa_frame_size(&This->ss));
4 Dec
4 Dec
11:26 a.m.
New subject: winepulse test data review
Maarten Lankhorst wrote:
I'm using the data that you sent me, nothing invisible.
So it's simply GetPosition vs. the HighPerformanceTimer output, as seen in:
render.c:1194: hpctime 481 pcpos 492
render.c:1199: padding 1250 position 510000/21250 slept 470ms iteration 0
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.
Delta
shouldn't be so high, are you using the timestamps from IAudioClock2::GetPosition ?
If you say jitter is 8 ms (which I find very high), you
wouldn't notice that extra 10 ms..
I simply compared GetPosition advancement
with wall time as reported by the HPC (relying
on file buffering to ignore delays introduced by logging output).
I prefer to just report the values from pulseaudio
directly.
Reasonable and probably good enough.
Some interruption of the audio stream, that sleep(i %
10) is suspect... what are you really testing there?
That sleep serves to prove my hypothesis that upon receiving an event from mmdevapi, any
app has nearly
one period time to feed (at least) one period worth of samples to mmdevapi.
I.e. conceptually, mmdevapi calls SetEvent() after performing one round of mixing and
decrementing padding.
It then goes to sleep until the next period tick.
Native plays that test glitch free on real hardware.
And that test seems to be sensitive to not being run in
realtime,
it seems to work slightly better if I change that to if I set
THREAD_PRIORITY_TIME_CRITICAL on the thread
RT probably helps, however I claim that *IF* Linux is able to deliver a sustained 10ms
rate to any app
without RT, then Wine (as an app) should be able to feed data to the audio every 10ms.
The mmdevapi design is such that the client app has nearly 10ms to feed new data -- by
design!
That is why the sleep(8ms) is perfectly valid -- given a 10ms period -- albeit stressing
(and sensitive to
the Linux scheduler delaying execution of the client thread).
What I want to emphasize is that there would be a design bug in a wineXYZ.drv mmdevapi
driver if it would depend
on a client app to react within say 2ms upon SetEvent. I repeat that the app has nearly
10ms time,
e.g. DSound can consume nearly 10ms to perform its mixing and HQ resampling in mmdevapi
event based mode.
I think this is a nice property of mmdevapi.
That is why we've the silence lead-in in winealsa.drv... It shall guarantee that ALSA
has enough samples to play
until the next period tick (if the Linux scheduler then calls the driver in time).
Here and then I've also reported that since the introduction of the completely fair
scheduler,
Linux appears *UNABLE* to sustain a periodic 10ms or even a 50ms rate without RT. This
affects not only audio.
The former scheduler found IIRC in 2.6.18 performed much better at games, both audio and
video glitches.
If you are a gamer, use one of the old kernels!
Sleep(0) (for i%10 = 0) looks kind of wrong though
That's just ok and the typical scenario where the client app react immediately
to SetEvent.
I may also be hitting some pulseaudio bug though, if I
play some music on the background when one
[...] that would explain why I'm getting interruptions like the +14 ms above..
I'm sorry but I did not understand that whole paragraph.
Regards,
Jörg Höhle
4184
days inactive
4223
days old
3 comments
2 participants
participants (2)
-
Joerg-Cyril.Hoehle＠t-systems.com -
Maarten Lankhorst