July 2012 - Wine-devel - list.winehq.org

[PATCH] winepulse.drv: Add PulseAudio driver
by Joerg-Cyril.Hoehle＠t-systems.com 04 Jul '12

04 Jul '12

Hi, >If you don't paste all the mmdevapi tests with the fix in my git tree, it's a >regression. I don't want to see held_Frames because it's a shadow buffer. >If winmm and dsound don't work without it, they're wrong, fix those. I won't comment on the two individual pulseaudio drivers. Unfortunately, none of the two authors bothered to point me to a verbose log of the mmdevapi tests for my scrutiny. The tests should pass like they do on native. Regarding latency, I'm not aware of a flaw in Wine's winmm. HOWEVER, Wine's DSound needs a patch. Here the reason. To recap, latency is somehow related to the "distance" between what one hears and the PCM frames sent to the device. GetPosition is the only API call in that area in both winmm and mmdevapi. Buffer size is a completely different thing. I find it useful to have in mind a cascade of audio filters performing some buffering each. Then it's obvious that an app only sees the frontmost buffer size and knows nothing about the others. High latencies imply that there must be some large buffer space(s), somewhere. Period is an artificial entity related to how often the frontmost buffer is drained to feed the next buffer in the chain, in case that happens regularly. This is not guaranteed nor necessarily documented. You get the idea: regardless of arbitrary (front) buffer sizes and periods not worth this name, try and send a stable flow of data to play music without glitches and let explosions be heard ASAP. So far the situation, now the issue. It appears easier to write code that provides (frontmost) buffer space behaviour similar to native than one that provides similar latency. Alas, behaviour observable on MS-Windows differs from what we get with PulseAudio and some ALSA devices. Tests seem to indicate a latency of around 30-70ms from mmdevapi with MS-Windows. That good enough for games. OTOH if ALSA or PA gives us 2 seconds on Linux, that's a big cause of trouble. The authors of MS apps could never test them in an environment with such high latency. What happens with software not tested? It happens not to work. Two solutions: - Reduce actual latency or - lie about latency. Lying about latency causes apps to loose the ability to sync audio and video. However, given a choice between loss of lip sync and possible crashes or other weird behaviour because an app is executed in a environment that its developers never experienced, I consider the loss of lip sync to be less worrying. We designed the winealsa driver to accomodate an arbitrary latency and accept a large variation of periods. (Some bug report from Jack users seem to imply that it should accept even larger periods, e.g. 150ms, yet still pretend to use 10ms on the mmdevapi side). We choose to have the winealsa driver not lie about latency. That should be left to high level APIs. DirectSound is built around the "Direct" HW (lack of) abstraction: a circular buffer of samples is played by a DAC. The converted signal is immediately sent to the speaker. Hence: 1. GetPosition information in the DSound abstraction translates to a "playpos" -- well known. 2. No provision is made for additional buffering. The playpos must lie within the circular buffer. The reported free (writable) space shall never cross the playpos -- with subtle consequences. Wine's DSound needs a patch to ensure this second property. Given a 80ms primary buffer, Wine's DSound must not pretend its playpos is 2 seconds late! I think Wine should try and reduce latency but lie if that does not suffice. What's needed? 1. Have DSound always use a buffer large enough for typical situations (I believe 100-200ms). 2. Clamp the reported position such that it won't leave the (virtual) primary buffer. As a result, DSound must pretend to play even when Wine is solely pumping the huge 2s of cascading SW audio buffers. 3. Work on reducing the latency of the cascading audio filters. That device-level work is independent on the DSound one. Native's 30-70ms has the benefit that it nicely fits within typical DSound primary buffer sizes. PulseAudio's 2s does not (yet). I believe a total 80ms latency would be acceptable with games. Further areas of investigation and effort: - Maybe clamp latency in the mmdevapi drivers after all? After all, huge latencies are known to cause dead-locks in apps and we don't know what all apps or libraries built atop mmdevapi or winmm expect. (If yes, to what value? 150% buffer size?) - Try and find MS setups with huge latencies. USB headphones are said to be candidates, but I've yet to see an excellent and trustworthy report about what happens in that case. - Work on reducing the cascades of audio buffers - Work on further decoupling mmdevapi periods from UNIX audio API ones - Research the trade-off between glitch free playback and buffering in UNIX. The current settings in Wine's audio are IMHO not good enough yet. Regards, Jörg Höhle

2 1

Re: [1/4] gdiplus: Add a test for font and graphics using different base units. Resend.
by Vincent Povirk 04 Jul '12

04 Jul '12

> +todo_wine > + expectf(102.499985, bounds.Width); Please don't hard-code string widths in your tests. It's not likely or desirable to get them exactly right.

2 1

New Wine Gecko 1.7-beta1
by Jacek Caban 04 Jul '12

04 Jul '12

Hi all, It's a bit sooner for another Gecko update than usually. This is caused by the fact, that many existing bugs in our MSHTML are blocked by another bugs, which require Gecko changes for proper fix. These changes enable using Gecko's cycle collector to understand our objects. This solves quite a few problems. The update also contains merged Firefox 14 beta changes. To test it, download Wine Gecko [1] and install it as usually [2]. You will also need the attached patch. The patch contains not only Gecko API changes, but also partial (but substantial enough for test to be meaningful) support for cycle collector in MSHTML. You may find some bugs already fixed by this patch. Any help with testing will be appreciated. Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.7-beta1/ [2] http://wiki.winehq.org/Gecko

1 0

Re: League of Legends patches
by Dan Kegel 04 Jul '12

04 Jul '12

On Tue, Jul 3, 2012 at 1:08 AM, Andrea Canciani <ranma42(a)gmail.com> wrote: > I tried to follow the http://wiki.winehq.org/SubmittingPatches > guidelines, but this is my first submission to wine, so I guess the > patches might need further improvement. > Please point out any issues that need fixing. On an administrivial note, you should send one patch per email to wine-patches. Do you think you could write a test that (semi-)reliably causes the deadlock you're fixing? > The patches have been tested by Dan Kegel (in CC) and are currently > being used by many MacOSX and Linux users to run LoL. Our emails may have crossed - with these patches applied, dlls/ieframe/tests/webbrowser.ok seems to crash here: Unhandled exception: privileged instruction in 32-bit code (0x02786624). Backtrace: =>0 0x02786624 (0x0032fcd8) 1 0x688e22db func_webbrowser+0x3ca() [dlls/ieframe/tests/webbrowser.c:3382] Otherwise the tests seem to pass. Thanks, Dan

3 3

Re: [3/4] gdiplus: Add some tests for GdipGetPropertyItemSize and GdipGetPropertyItem. Take 2.
by Marvin 04 Jul '12

04 Jul '12

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=19764 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

2 1

Re: [4/4] gdiplus: Add a bunch of tests for TIFF image properties. Resend.
by Marvin 04 Jul '12

04 Jul '12

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=19765 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH 3/4] vbscript: Fixed function return crossing for loop
by Marvin 03 Jul '12

03 Jul '12

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=19753 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 === 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

1 0

Re: [PATCH 4/4] jscript: Added more apply and call tests
by Marvin 03 Jul '12

03 Jul '12

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=19754 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0

Re: [PATCH 2/4] vbscript: Fixed 'exit do' statements crossing for in loops
by Marvin 03 Jul '12

03 Jul '12

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=19752 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 === 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

1 0

Wine on the front page of Reddit
by Caleb Hearon 03 Jul '12

03 Jul '12

Hi all, In a conversation between myself (MaggotBrain on the forums) and Jarrex, I expressed some frustration that Blizzard had been banning Diablo III users who used Wine. He posted some of the excerpts I sent him from WineHQ, and it quickly got to 17 pages on Blizzard's forums. http://us.battle.net/d3/en/forum/topic/5978861022 Then it made the front page of Reddit with 25k votes! http://www.reddit.com/r/gaming/comments/vyc4z/linux_users_permanently_banne… It's likely a mistake on Blizzard's part. But I thought this might be interesting to some people here. It's amazing that this conversation I had while at work led to more widespread awareness of Wine (one of the top comments on Reddit asks what Wine is). And Wine hackers- great work, I've just finished playing 2 hours of Diablo III and it runs great. -Caleb

2 1