December 2012 - Wine-Devel - list.winehq.org

re: Clang static analyzer results / wine-1.5.19-186-g1cd0c4a

by Dan Kegel

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

Dec. 22, 2012

Re: dsound: use event based threads, v2

by Maarten Lankhorst

Op 21-12-12 18:44, Joerg-Cyril.Hoehle(a)t-systems.com schreef: > 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? Because the timeout is not meant to be something that normally should ever be hit normally, it's just an upper bound on how long we would be prepared to wait in case something does mess up. > >> 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 20ms 10ms > 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 7 1 7 > 1 8 10 8 > 2 9 2 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. It's holding 8 periods, it just refills a maximum of 3 periods at a time. With a timeout upper bound of 2.5 periods, it would keep up on average even if nothing is moving forward.. > You advertised RT priorities. With them, the picture would look different of course. > A faster machine helps too... I never looked at winealsa, I'm scared by the memory allocations in dsound inside the mixer thread, instead of just allocating some upper bound, so I never wanted to see closely at how the rest of the stack behaves.. Not sure what winealsa thread is actually doing, but it should really just do as little as possible, and if it keeps any locks, all other paths that could end up taking the same locks should be audited in a similar way with suspicion. Even if it's not actually elevated to rt , it should act as though it is, since any improvements also benefit upper bound without -rt.. > 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. > It would also be interesting if you have any suggestions on how to improve winepulse, and if there are still outstanding differences wrt to native mmdevapi. With that latency fix I may look into enabling exclusive mode again, as it was probably hit extra hard by that pulseaudio bug. ~Maarten

Dec. 22, 2012

dsound: use event based threads, v2

by Joerg-Cyril.Hoehle＠t-systems.com

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 20ms 10ms 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 7 1 7 1 8 10 8 2 9 2 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

Dec. 21, 2012

Re: Need help to install Xlib/xfree86 devlopnemt packeg in ubuntu 10 LTS

by Frédéric Delanoy

On Thu, Dec 20, 2012 at 6:25 AM, Hamid Lohar <hmdlohar(a)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

Dec. 21, 2012

Re: dsound: use event based threads, v2

by Maarten Lankhorst

Op 21-12-12 11:59, Joerg-Cyril.Hoehle(a)t-systems.com schreef: > 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.6666ms too close to the DefaultPeriod of > 10.0000ms to tell for sure which is used as the average period. > <snip> Because I'm using it later on in the rework to tell how much to queue. 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. This is why I choose streamlatency instead of getdeviceperiod. Also since it may be a different value, who says it's only going to be bigger than the default period? It could theoretically be smaller, still.. ~Maarten

Dec. 21, 2012

Re: msvcrt: fix prototypes ov _execvp, _wexecvp, _execvpe and _wexecvpe

by Alexandre Julliard

Jérôme Gardou <jerome.gardou(a)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 julliard(a)winehq.org

Dec. 21, 2012

Re: jscript: Added null and undefined values support to to_object

by Marvin

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

Dec. 21, 2012

Re: [1/2] wineps.drv: Add an ability to select device resolution from UI.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)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.

Dec. 21, 2012

Re: [PATCH 2/2] msvcr100: Added _aligned_msize implementation

by Marvin

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

Dec. 21, 2012

Re: [1/2] wineps.drv: Add an ability to select device resolution from UI.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)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 julliard(a)winehq.org

Dec. 21, 2012