mmdevapi: Avoid lock contention after SetEvent.
Andrew Eikum asked: Is it true that SetEvent() causes a context switch? Looking at +tid log files, I've seen switches happen after SetEvent often enough. That motivated some changes to winmm notification in the last years, i.e. call SetEvent after all local work is finished and objects are in a sane state again. Moreover, the semantics of SetEvent is that it puts any thread waiting for the event into runnable state. If it's runnable, the OS may as well decide to run it. And that's exactly what happens. On a multi-core system, the signaled thread may start running immediately on another core. You don't want it to stop shortly later, blocking on wineXYZ*.drv's sole critical section when invoking mmdevapi. LeaveCriticalSection is another place where context switches happen, both according to log files and by design (see RtlUnWaitCriticalSection). So could moving SetEvent after LeaveCS disturb the dynamic behaviour of winealsa.drv? I argue that there's no harm, because mmdevapi's design is such that the app has nearly one period time after receiving the event to supply new samples. Thus if an app manages to sneak in a call unblocked by LeaveCS, e.g. GetPosition, before SetEvent, there should still be enough time left afterwards. In any case, lock contention by an app calling GetPosition during the period callback is presumably rare, while lock contention by SetEvent vs. GetCurrentPadding in the signaled thread, e.g. DSound is systematic. So let's avoid it. (Please don't skip that patch waiting for the lock-less one which will render it superfluous...). Regards, Jörg Höhle
dsound: use event based threads, v2
Maarten, +hres = IAudioClient_GetStreamLatency(device-client, period); +device-sleeptime = period_ms * 5 / 2; + ret = WaitForSingleObject(dev-sleepev, dev-sleeptime); Although it's a minor point, as we're solely discussing the case of the timeout when mmdevapi doesn't call SetEvent, I wonder why you insist on using GetStreamLatency as the basis of your timeout computations instead of GetDevicePeriod. You know that wineXYZ.drv use the device period as the basis for their SetEvent, thus IMHO the timeout too should be based on it, instead of a GetStreamLatency we know next to nothing about. If you visit testbot jobs 23521 and 23514, you'll see that I've measured the event rates. Sadly, all testbot VMs report a GetStreamLatency of 10.ms too close to the DefaultPeriod of 10.ms to tell for sure which is used as the average period. W7 and w2k8 machines seem to use DefaultPeriod: render.c:185: Returned periods: 10. ms 3. ms render.c:333: Returned latency: 10. ms render.c:626: event after Start average 10.004ms render.c:2206: event average 9.992ms sigma 0.447 Vista may use its reported StreamLatency as period: render.c:185: Returned periods: 10. ms 3. ms render.c:333: Returned latency: 10. ms render.c:626: event after Start average 10.697ms render.c:2206: event average 10.736ms sigma 0.834 The one w2k8 machine is peculiar as it appears to use the 15.600ms (or 15.625ms?) timers well known from pre-Vista times: render.c:185: Returned periods: 10. ms 3. ms render.c:333: Returned latency: 10. ms render.c:626: event after Start average 15.547ms render.c:2206: event average 15.625ms sigma 5.625 However, the rate is certainly not the 20-30ms StreamLatency that e.g. winealsa returns. Regards, Jörg Höhle
Re: winepulse test data review
Op 04-12-12 14:28, joerg-cyril.hoe...@t-systems.com schreef: Hi, Maarten Lankhorst wrote: Actually in winepulse, sleep / 12000 (8 ms I guess?) ms would work, no sleep at all works too, Yes, I wanted to go no further than 8ms below the 10ms period limit. it was just the mixing of various levels of sleep that was failing. Not sure why though, might be something about the scheduling throwing it off. There's a perfectly simple explanation of this that applies to both winepulse and winecoreaudio. It goes as follows. IOW, there's a bug in winecoreaudio. It may explain why the test stutters on my MacOS 10.5.8 machine, regardless of how accurate or improved GetPosition is. winecoreaudio's IAC_ReleaseBuffer sends packets off as soon as it receives data, unlike winealsa/wineoss. Consider the sleep sequence 0 5 8 0 5 ms... + The transition 8 - 0ms sleep is fine, as data is sent 2ms after the prior packet - The transition 0 - 5 is most problematic, as it means that 2 ReleaseBuffer will be 15ms apart, even though only 10ms of data was sent. I believe winepulse is affected by this too, like winecoreaudio. The stable sequences always 0 or always 8ms sleep are paced regularly, so underruns are avoided as long as the OS schedules the threads soon enough. Winealsa and wineOSS are not affected, as they write data on the 10ms period boundaries, -- like native presumably does. winecoreaudio solution paths: - write packets on period tick, not at release time - or add silence lead-in - or delay first packet until period tick only (if small) - or ... I think it should be possible to produce reliable continuous sound in winepulse and winecoreaudio yet maintain their current send packet codebase instead of transitioning to a separate buffer that winealsa and wineoss use. Actually, Arun Raghavan found this thread and pointed me towards updating pulseaudio, it seems it was a bug in pulseaudio fixed in 3.0: Op 20-12-12 12:43, Arun Raghavan schreef: Hi Maarten, While following some random thread, I cam across this: http://www.winehq.org/pipermail/wine-devel/2012-December/098008.html I see you mention: 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. We recently fixed a bug where pausing and resuming a stream could end up adding a hidden latency to the stream, and this would not happen if another stream was playing. The fix is in 3.0, so if this is what you were referring to, might be worth trying with newer PA. This does make my life a lot easier though, as finding a way to only queue on multiple of periods was giving me a headache, results from 10 seconds now: render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -881 frames at 44100 worth 9990ms in 9983ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -882 frames at 44100 worth 9990ms in 9990ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -882 frames at 44100 worth 9990ms in 9988ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -881 frames at 44100 worth 9990ms in 9987ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -682 frames at 44100 worth 9995ms in 9986ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -724 frames at 44100 worth 9994ms in 9987ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -881 frames at 44100 worth 9990ms in 9984ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -767 frames at 44100 worth 9993ms in 9989ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -441 frames at 44100 worth 1ms in 9991ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -882 frames at 44100 worth 9990ms in 9988ms render: 41019 tests executed (0 marked as todo, 0 failures), 0 skipped. I would be interested in the exact commit though, so I can get it backported to precise/quantal, from ubuntuforums' winepulse thread it seems I'm not the only one that might have been hitting this problem. ~Maarten
Re: winepulse test data review
On Thu, 2012-12-20 at 13:34 +0100, Maarten Lankhorst wrote: Op 04-12-12 14:28, joerg-cyril.hoe...@t-systems.com schreef: Hi, Maarten Lankhorst wrote: Actually in winepulse, sleep / 12000 (8 ms I guess?) ms would work, no sleep at all works too, Yes, I wanted to go no further than 8ms below the 10ms period limit. it was just the mixing of various levels of sleep that was failing. Not sure why though, might be something about the scheduling throwing it off. There's a perfectly simple explanation of this that applies to both winepulse and winecoreaudio. It goes as follows. IOW, there's a bug in winecoreaudio. It may explain why the test stutters on my MacOS 10.5.8 machine, regardless of how accurate or improved GetPosition is. winecoreaudio's IAC_ReleaseBuffer sends packets off as soon as it receives data, unlike winealsa/wineoss. Consider the sleep sequence 0 5 8 0 5 ms... + The transition 8 - 0ms sleep is fine, as data is sent 2ms after the prior packet - The transition 0 - 5 is most problematic, as it means that 2 ReleaseBuffer will be 15ms apart, even though only 10ms of data was sent. I believe winepulse is affected by this too, like winecoreaudio. The stable sequences always 0 or always 8ms sleep are paced regularly, so underruns are avoided as long as the OS schedules the threads soon enough. Winealsa and wineOSS are not affected, as they write data on the 10ms period boundaries, -- like native presumably does. winecoreaudio solution paths: - write packets on period tick, not at release time - or add silence lead-in - or delay first packet until period tick only (if small) - or ... I think it should be possible to produce reliable continuous sound in winepulse and winecoreaudio yet maintain their current send packet codebase instead of transitioning to a separate buffer that winealsa and wineoss use. Actually, Arun Raghavan found this thread and pointed me towards updating pulseaudio, it seems it was a bug in pulseaudio fixed in 3.0: Op 20-12-12 12:43, Arun Raghavan schreef: Hi Maarten, While following some random thread, I cam across this: http://www.winehq.org/pipermail/wine-devel/2012-December/098008.html I see you mention: 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. We recently fixed a bug where pausing and resuming a stream could end up adding a hidden latency to the stream, and this would not happen if another stream was playing. The fix is in 3.0, so if this is what you were referring to, might be worth trying with newer PA. This does make my life a lot easier though, as finding a way to only queue on multiple of periods was giving me a headache, results from 10 seconds now: That's good to hear. render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -881 frames at 44100 worth 9990ms in 9983ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -882 frames at 44100 worth 9990ms in 9990ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -882 frames at 44100 worth 9990ms in 9988ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -881 frames at 44100 worth 9990ms in 9987ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -682 frames at 44100 worth 9995ms in 9986ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -724 frames at 44100 worth 9994ms in 9987ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -881 frames at 44100 worth 9990ms in 9984ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -767 frames at 44100 worth 9993ms in 9989ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -441 frames at 44100 worth 1ms in 9991ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -882 frames at 44100 worth 9990ms in 9988ms render: 41019 tests executed (0 marked as todo, 0 failures), 0 skipped. I would be interested in the exact commit though, so I can get it backported to precise/quantal, from ubuntuforums' winepulse thread it seems I'm not the only one that might have been hitting this problem. The bug becomes really visible when your stream requests a high latency (and no other stream with a lower
Re: [PATCH] loader: Use a volatile pointer in wld_memset().
Charles Davis cdavi...@gmail.com writes: This prevents Clang from optimizing the loop into a memset(3) call. Something like -fno-builtin would be preferable. -- Alexandre Julliard julli...@winehq.org
Re: [1/2] wineps.drv: Add an ability to select device resolution from UI.
Alexandre Julliard julli...@winehq.org wrote:
@@ -224,10 +229,13 @@ typedef struct
static INT_PTR CALLBACK PSDRV_PaperDlgProc(HWND hwnd, UINT msg,
WPARAM wParam, LPARAM lParam)
{
+ static const WCHAR resW[] = {'%','d',' ','d','p','i',0};
+ static const WCHAR resxyW[] = {'%','d','x','%','d',' ','d','p','i',0};
The dpi string needs to be loaded from resources.
Actually I did that, but then tested under Russian Windows7 and it's 'dpi'
there, so I'd assume that it's either considered as a common term, or it's
driver dependent (although all remaining driver UIs are in Russian here).
If you still think that it should be translated please let me know.
+data = HeapAlloc(GetProcessHeap(), 0, sizeof(*data));
+data-resx = data-resy = di-pi-ppd-DefaultResolution;
+SendDlgItemMessageW(hwnd, IDD_QUALITY, CB_SETITEMDATA, 0,
(LPARAM)data);
+Cursel = 0;
You don't need a data structure, you can store the values directly with
something like MAKELONG.
Good point, thanks.
--
Dmitry.
Re: [1/2] wineps.drv: Add an ability to select device resolution from UI.
Dmitry Timoshkov dmi...@baikal.ru writes: Actually I did that, but then tested under Russian Windows7 and it's 'dpi' there, so I'd assume that it's either considered as a common term, or it's driver dependent (although all remaining driver UIs are in Russian here). If you still think that it should be translated please let me know. Sure, I see no reason to hardcode it. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 2/2] msvcr100: Added _aligned_msize implementation
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=23573 Your paranoid android. === W7PROX64 (64 bit msvcr100) === msvcr100.c:344: Test failed: _aligned_msize returned 23 msvcr100.c:346: Test failed: _aligned_msize returned 23 msvcr100.c:348: Test failed: _aligned_msize returned 23 msvcr100.c:350: Test failed: _aligned_msize returned 24 msvcr100.c:357: Test failed: _aligned_msize returned 3 === TEST64_W7SP1 (64 bit msvcr100) === msvcr100.c:344: Test failed: _aligned_msize returned 23 msvcr100.c:346: Test failed: _aligned_msize returned 23 msvcr100.c:348: Test failed: _aligned_msize returned 23 msvcr100.c:350: Test failed: _aligned_msize returned 24 msvcr100.c:357: Test failed: _aligned_msize returned 3
Re: jscript: Added null and undefined values support to to_object
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=23578 Your paranoid android. === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found
Re: msvcrt: fix prototypes ov _execvp, _wexecvp, _execvpe and _wexecvpe
Jérôme Gardou jerome.gar...@reactos.org writes: --- dlls/msvcrt/process.c |8 1 file changed, 4 insertions(+), 4 deletions(-) You should also fix the corresponding headers and remove the typecasts. -- Alexandre Julliard julli...@winehq.org
Re: Need help to install Xlib/xfree86 devlopnemt packeg in ubuntu 10 LTS
On Thu, Dec 20, 2012 at 6:25 AM, Hamid Lohar hmdlo...@gmail.com wrote: I am installing it from source file (wine 1.5.x.tar.bz2) by running wine install i get error x support not found, wine can not fount x, please instal xlib/xfree86 devlopment files. That is the error. You need to install your X development files (that depends on your distribution, e.g. libx11-dev) for compiling wine. Most likely, you shouldn't do that, and instead use prepackaged (binary) versions of wine = http://www.winehq.org/download/ Again, you should ask such questions on wine-users or the wine forum (http://forum.winehq.org/) Frédéric
dsound: use event based threads, v2
Hi, Maarten Lankhorst answered: [...] I wonder why you insist on using GetStreamLatency as the basis of your timeout computations instead of GetDevicePeriod. Because I'm using it later on in the rework to tell how much to queue. Ah. But why not use the correct tool for the correct job? GetPeriod for period, and StreamLatency for buffer and queue sizes? In my rework, I try to write at most 3 * GetStreamLatency, so even if for some reason no event is ever delivered, you would never get an underrun. I'm sorry to disagree, but I've conducted numerous tests last night. The results are very disappointing, but I'll only find time in January to write more about it. Basically, no trick in DSound or Winmm whatsoever can prevent an underrun. The typical Linux machine can and will not schedule arbitrary threads that are ready to run, and I observed arbitrary pauses of 12-120ms. :-( How much was wake up delayed? For lovers of histograms: sort -n delays | uniq -c period 20ms10ms 57 0 828 0 41 1 202 1 2767 2 2771 2 541 3 185 3 258 4 1956 4 6 5 16 5 22 6 13 6 5 71 7 1 8 10 8 2 92 9 11 10 3 10 4 11 1 12 9 12 1 13 1 13 2 14 1 16 1 18 1 34 1 88 1 119 3716 samples 6005 - Even if mmdevapi SetEvent's your thread, there's no guarantee that it gets scheduled without or with little delay. - Above data is for one thread. As multiple threads are involved in producing audio, delays accumulate. - Even if the DSound thread always gets to run and Release's data, there's no guarantee that the winealsa.drv thread does and sends data to ALSA. - Worse, even if the winealsa thread gets to run, there's no guarantee *AT ALL* (and I've seen it happen) that it won't lose CPU for over 20ms even if calling nothing but snd_pcm_* (and TRACE) in the callback. As a consequence, the current winealsa.drv can, by design (ALSA buffer holding no more than 3 periods), not prevent underruns, no matter how much you kick it. You advertised RT priorities. With them, the picture would look different of course. A faster machine helps too... In January, I'll write more, e.g. about concrete changes in code. BTW, yesterday I replaced the timer queues in winealsa with an own thread. Timing is much better, but that doesn't prevent delays. More changes are needed to improve the situation. Regards, Jörg Höhle
re: Clang static analyzer results / wine-1.5.19-186-g1cd0c4a
I had a look at a couple warnings, e.g. file:///home/dank/Downloads/scan-build-2012-12-18-1/report-z07lcL.html#EndPath file:///home/dank/Downloads/scan-build-2012-12-18-1/report-9D2p5I.html#EndPath They're hard to follow, but mostly look like garbage :-( Too bad there's no web interface for marking them as checked. This one's real, but only affects a trace, and only if send fails: file:///home/dank/Downloads/scan-build-2012-12-18-1/report-RBGMAQ.html#EndPath
