November 2011 - Wine-Bugs - list.winehq.org

[Bug 28723] Sound stutter in Rage when emulated windows version is set to "Windows 7" (XAudio2 -> mmdevapi sound output path)

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=28723 --- Comment #59 from Alexey Loukianov <mooroon2(a)mail.ru> 2011-11-30 06:21:08 CST --- (In reply to comment #58) > >when I request 20ms buffer for 44100Hz stream I got 896 samples buffer > I conclude that you have an Intel HDA. That uses no 10ms period rather than a > 10.1587ms one with 448 frames. IOW, you need to repeat your tests (441->448)! Actually it isn't Intel HSA, it's rather Conexant HDA codec sitting on HDA-bus. Nevertheless reported default period is really 448f. As for repeating tests - actually I've done testing with chunk_size = buffer_size >> 1, which is exactly 448f for 896f buffer. > .. yet the following code predicts non-HDA engines... > (lisp black magic follows) Oh my, there are some programming languages out there that I'm not comfortable with (IOW don't like them and/or find their syntax/concepts too confising). Lisp is one of those, other are prolog, perl, python :-). Would have to smoke in common list specs to decypher that cryptic construct to something that looks like more traditional-math like. > It would be good if you could find the correct formula for exclusive > mode with Intel HDA. I hadn't even touched the exclusive mode in my tests yet. And I'm a bit curious are there any real-world apps out in the wild which use exclusive mode? > Well, Alexey even complains about 5ms :-) That's not complaints, it just the observation of the behavior that differs when running testcase on Win7 vs. Wine :-). > Alexey's comment is a bit troubling. If there was a 28ms lag while > feeding data, I'd expect GetPosition to slowly reach sum_written > within 28ms after feeding ends. Yeah, that's what exactly happens. > He seems to say that GetPosition is bumped to sum_written as > soon as there's no more data to feed. This would be important > behaviour to mimic. No-no-no, sorry for not being clear in my original comment. With both Wine and Win7 I've got devposition steadily increasing up to but no more than the amount of data I had pumped out to the audio engine. If I stop pumping the data out and start polling the value returned by IAudioClock_GetPosition - I get devpos steadily approaching the samples_written count and stay there constantly until I pump out some more data. Note, that this behavior is not the case for the devpost value returned by IAudioClock2_GetDevicePosition - it is totally different beast affected by devpos backwards jumps to 0 on hardware underruns and maybe some other circumstances I hadn't discovered yet. > ---- Alternatives > ... Hmm, your pseudocode looks promising but I have a couple of questions concerning it: 1. Does it really matters would we write out data on each event or not if we still would be receiving timer callbacks every 10ms? The only real possible benefit I see is that we would kind-a be "protected" from "skips" in output stream when the system wouldn't be able to schedule out timer callback timely due to something like paging or executing some other high-prio thread. That's a good reason on its own but only in case actual implementation wouldn't be excessively complicated. 2. What is "gcp" here? GetCurrentPadding? held_frames? Something else? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Nov. 30, 2011

[Bug 27650] World of Warcraft Launcher 4.2 crashes on initialisation

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=27650 ladymisspi(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ladymisspi(a)gmail.com --- Comment #18 from ladymisspi(a)gmail.com 2011-11-30 05:57:47 CST --- I've been having the same problem others above have been. The suggested actions worked like a charm for me as well. Thank you very much for posting this. (In reply to comment #16) > I was pointed to a workaround on a separate bug that I'd like to request some > of you try. > > Rather than running the Launcher to update WoW, run the > BackgroundDownloader.exe in the WoW directory, and as soon as it opens, go into > the preferences for that app, disable Peer to Peer downloading, and enable > "Don't throttle background download". Then exit the background downloader, run > the launcher and see if you still get the same issue. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Nov. 30, 2011

[Bug 25742] Heap tagging API not implemented

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=25742 rigtig(a)iinet.net.au changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rigtig(a)iinet.net.au --- Comment #4 from rigtig(a)iinet.net.au 2011-11-30 04:30:56 CST --- I checked the source code for wine 1.3.31 and found the ntdll.spec has a line "@ stub RtlCreateTagHeap". So, I abandoned looking for resolution in wine. I copied ntdll.dll from Win7 system that does run innoWorkshop2, deleted the existing one from .wine/drive_c/windows/system32/ and still get same messages (different addresses each time). I don't know enough about .DLL file format to be sure .RtlCreateTagHeap does exist, but there are relevant error messages in the .DLL file from Win7. Is it possible that the first line of the output gives the clue to the cause? (that cannot navigate the .DLL). Can anyone think of anything else to check, or try? And yes, using winecfg, I did set he innoWorkshop2.exe to run under Win7. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Nov. 30, 2011

[Bug 28723] Sound stutter in Rage when emulated windows version is set to "Windows 7" (XAudio2 -> mmdevapi sound output path)

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=28723 --- Comment #58 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2011-11-30 04:07:41 CST --- >when I request 20ms buffer for 44100Hz stream I got 896 samples buffer I conclude that you have an Intel HDA. That uses no 10ms period rather than a 10.1587ms one with 448 frames. IOW, you need to repeat your tests (441->448)! >((20ms * nSamplesPerSec)/16 + 1)*16 Some month ago, I tried to predict buffer sizes etc. in shared and excl. mode. I wasn't successful with the HDA's alignment requirements, yet the following code predicts non-HDA engines. Note the differences in rounding (round is like MulDiv, unlike floor & ceiling etc. -- see the Common Lisp HyperSpec). In particular, round is not C's / operator. (defun mmdevapi (duration period freq) (let* ((shared (round (* (float duration) freq) 10000000)) (fragment (round (* (float period) freq) 10000000)) (parts (round (float duration) period)) (partu (ceiling (float duration) period))) (list shared fragment parts (* fragment parts) (* (round (* fragment partu) 128) 128)))) (mmdevapi 5000000 101587 44100) It would be good if you could find the correct formula for exclusive mode with Intel HDA. >using 32bit IEEE_FLOAT FP is convenient for mixing, but I'd expect the output of the mixer to be typical 16 bits. OTOH, some cards *do* support FP, so why would native perform an extra conversion then? ---- GetPosition AE>I removed the upper bound (5 seconds) on delay_frames in GetPosition(). AE>How strongly do you feel we need that type of logic? Well, Alexey even complains about 5ms :-) AL>With Wine I still got devposition lagging behind about 5ms I introduced that logic to specifically acknowledge the idea that a true speaker position may be up to 5s behind the audio data we feed in the presence of *huge* latencies (audio over a network?). Latencies cause speakers to continue playing even after the front buffer hits an underrun. GetPosition MUST ensure that it'll reach sum_written eventually. Removing that logic also removed the underrun protection that worked in free-running mode. Something else is needed with the current XRUN=>stop mode. Hopefully I can complete my GetPosition patch tonight. I'll also add the "IAC_Stop must not use snd_pcm_drop" one to pass even more of my render tests. Alexey's comment is a bit troubling. If there was a 28ms lag while feeding data, I'd expect GetPosition to slowly reach sum_written within 28ms after feeding ends. He seems to say that GetPosition is bumped to sum_written as soon as there's no more data to feed. This would be important behaviour to mimic. Can you add please some logs to show this and report back? ---- Log File Analysis Analysis of my WINETEST_DEBUG=2 render.ok output shows that GetPosition is 41-83ms(!) behind frames_written-padding in Wine with the 4 patches from comment #54, and while GetPosition advances as regularly as the high performance counter, it's the padding that varies wildly at each iteration. The cause is probably the large ALSA period with dmix: AudioClient_Initialize ALSA buffer size: 8192 frames AudioClient_Initialize ALSA period size: 1024 frames AudioClient_Initialize MMDevice period: 480 frames AudioClient_Initialize MMDevice buffer size: 24000 frames or (period still not being ignored in shared mode): AudioClient_Initialize MMDevice period: 720 frames ---- Patches & Ownership I claim 0002. Date: Wed, 2 Nov 2011 09:27:46 +0100 Subject: [PATCH] winealsa: Don't set ALSA's period time. http://www.winehq.org/pipermail/wine-patches/2011-November/108479.html Something is missing from patch 0003. IMHO, any patch that touches + if(period) + This->mmdev_period_rt = period; should clamp period and duration first, something like: if(!duration) /* 3 times is compatible with native and our requirements*/ duration = 3 * DefaultPeriod; if(SHAREDMODE){ This->mmdev_period_rt = DefaultPeriod; if(duration > 2s) 2s if(duration < 3 * DefaultPeriod) duration = 3 * DefaultPeriod; }else{ if(period < MinPeriod) ... if(duration ...) ---- Alternatives It's good news that your patch set works well (the key seems to be the ALSA buffer size limitation?). Here's what I had sketched during the last days. alsa_set_period_max 10ms /* guarantees start when writing 10ms */ alsa_set_buffer_min 30ms /* stream with at least 3 periods */ TODO set_buffer_max approx. duration, perhaps 30ms more when tiny. if (to_write){ if (alsa_pad <= 0 /* just starting */ && to_write <= 10ms){ /* we want 3 periods for streaming */ write(10ms silence lead); } write(alsa_avail); /* as much as possible, not 10ms */ /* alsa_buffer >= 20ms => will write at least 10ms initially */ } if(alsa_avail>=10ms) if(gcp>10ms) # gcp = max(0,gcp-10ms); gcp -= 10ms; else gcp = 0; It allows the callback to be late by up to 9ms in the case of Rage, but needs more thought about when the audio and system clocks differ or when e.g. due to system load or paging several events are missed. It should allow large ALSA buffers and a heuristic to write less often than every 10ms if ALSA already has a lot of data. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Nov. 30, 2011

[Bug 28730] The game "RAGE"crash at startup with "SetPixelFormat failed" error

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=28730 --- Comment #25 from Loris Zinsou <the-lz-himself(a)orange.fr> 2011-11-30 04:06:12 CST --- So that seems to be a nvidia issue ? What is the next step then (where to post about this and getting a chance of seeing this fixed) ? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Nov. 30, 2011

[Bug 17035] RPG Maker XP: Script editor selects complete script when program gets focus

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=17035 Mark Toman <kram1024(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kram1024(a)hotmail.com --- Comment #8 from Mark Toman <kram1024(a)hotmail.com> 2011-11-30 04:05:19 CST --- crossover wine is also effected by this bug. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Nov. 30, 2011

[Bug 11010] Application based on RPG Maker XP page faults shortly after select 'new game' from menu.

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=11010 Mark Toman <kram1024(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kram1024(a)hotmail.com --- Comment #7 from Mark Toman <kram1024(a)hotmail.com> 2011-11-30 04:03:12 CST --- crossover not effected, if still exists, Andrew may have an answer. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Nov. 30, 2011

[Bug 19566] RPG Maker XP RTP/Player: Failed To Load Archive

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=19566 Mark Toman <kram1024(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kram1024(a)hotmail.com --- Comment #10 from Mark Toman <kram1024(a)hotmail.com> 2011-11-30 04:00:31 CST --- rpg maker xp and vx 1.04E effected too with 1.3.29 even. Oddly crossover not effected by this bug. Maybe Andrew can help fix this. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Nov. 30, 2011

[Bug 20077] User Interface of RPG Maker XP is unusable and freezes

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=20077 Mark Toman <kram1024(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kram1024(a)hotmail.com --- Comment #6 from Mark Toman <kram1024(a)hotmail.com> 2011-11-30 03:55:47 CST --- I have noticed that some dialog boxes such as the map properties one only works with the keyboard and after a while the program freezes. both rpg maker xp and vx are effected. I am wondering, is this the same bug? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Nov. 30, 2011

[Bug 10791] RPG Maker XP 10.2a: Does not play Background Music (BGM) and Background Sounds (BGS)

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=10791 Mark Toman <kram1024(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kram1024(a)hotmail.com --- Comment #10 from Mark Toman <kram1024(a)hotmail.com> 2011-11-30 03:52:02 CST --- you need working directsound and directmusic with a gm.dls file. once we are ready to tackle that one, I am hoping with proper tools a wine based gm.dls can be made to solve this issue. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Nov. 30, 2011