December 2010 - Wine-Bugs - list.winehq.org

[Bug 25616] Comet Busters: Error displays indicating Wine cannot continue

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=25616 --- Comment #6 from Craig Schulstad <craig.schulstad(a)infor.com> 2010-12-26 21:33:26 CST --- Andrew, I am currently using version 1.3.9 of Wine. I just tried to get the update but when I ran the "sudo apt-get update..." command, I received a message back that I was at the current level of Wine. Evidently, the binary for Ubuntu has not been put into a distribution package yet. I will check tomorrow and the next day to see if version 1.3.10 is available. Once it is, I will retry Comet Busters. So I will probably make another post in a few days. I also went to your link and downloaded that version of Comet Busters which actually was slightly newer than the version I purchased some years ago. Thanks again for looking at this bug submission. Regards, Craig -- 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.

Dec. 27, 2010

[Bug 13019] Half-Life(CS 1.6): SoundBlaster Live - microphone output harshy and chopped

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=13019 --- Comment #32 from Raymond <superquad.vortex2(a)gmail.com> 2010-12-26 21:12:49 CST --- I guess the problem is in CS since some users also report the mic problem when using windows The other point is that snd-emu10k1 must use "front","rear" device for playback to front or rear jacks by changing the internal routing and application cannot use "front" device for capture This is the reason why wineoss does not work when wine are using ALSA's OSS emulation some version of PA server still use "front" device for both playback and capture since wine cannot use the old convention "default:x" to use the sound card x 's default device (i.e. "default" device in /usr/share/alsa/cards/EMU10k1.conf " when your linux distribution override the "default" device" by "pulse" add the following enty in your .asoundrc pcm.wine { type asym playback.pcm "front:0" capture.pcm "plughw:0,0" } http://wiki.winehq.org/UsefulRegistryKeys AutoScanCards="N" DeviceCount="1" DevicePCM1="wine" DeviceCTL1="hw:0" UseDirectHW="N" -- 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.

Dec. 27, 2010

[Bug 14717] resampled sound is horrible

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14717 --- Comment #78 from Raymond <superquad.vortex2(a)gmail.com> 2010-12-26 20:14:59 CST --- (In reply to comment #72) > Raymond, I am not sure that I understand what you demand. Could you please > confirm below each of these points whether we agree on it? > > 1. Windows has kmixer, the component that mixes and resamples sound. In Wine, > dsound-based resampling and mixing is done in dlls/dsound/mixer.c, by adding > the contents of secondary dsound buffers (stretched or shunk by duplicating or > dropping samples - that's important!) into primary. win98 did not has any kmixer The current implementation of wineoss and winealsa is a trimmed down version of vxd driver which provide software mixing in dsound and winealsa.drv still does not provide access to secondary hardware buffers of those hardware mixing sound cards THis mean that it does not support multiple waveoutopen bug#22880 Kmixer just set dwHwMixingBuffers,.... in DSCAPS so that dsound applications believe that all supported sound cards have hardware secondary buffers > > 2. Sound produced by the WaveOut API does not go through dlls/dsound/mixer.c > (tested with WinAmp), is not affected by the "default sample rate" setting, is > not resampled in Wine at all, and thus is not affected by this bug. yes , waveoutopen in winealsa.drv use the "default" device which you can override to use "hw" directly, dmix or pulse ( in the past, wine use default:x to use the default playback device of the sound card x ) >> It is affected by a valid bug 25587 in winejack, which existed before the patch and is a separate problem that this patch is not trying to solve. it is winejack incorrectly informed foobar that the it can support 44100Hz but you start jack server to run at 48000Hz, the only way is to use foobar's resampler or you add a resampler inside winejack. or winejack can stop the jack server and restart the jack server at the application's requested sample rate adding a cpu intensive resampler in dsound is a nightmare unless you implement an option to allow user to select the quality of SRC in winecfg. the default SRC quality should be the one with minimum CPU usage some windows drivers allow you to select the quality of the SRC instead of the sampling rate > > 3. The best quality is obtained when the application output is fed into the > hardware buffer of the sound card without any resampling, but this is not > always possible. Some professional users are looking for bit exact, no mixing , up-sampling or down sampling when listing music (i.e. no format conversion ) and it need the sound card support the sampling rate of the audio stream > > 5. When the application uses only secondary dsound buffers, wine opens its > backend (winealsa.drv or whatever) at the sample rate configured as the > "default sample rate" in winecfg. No, winejack does not support dsound, you can only use one of the wine audio driver at a time. The checkbox in winecfg mislead the user to believe that they can use any of them at the same time, but in fact wine only use the first checked driver in the list winecfg should use radio button instead of checkbox to select audio driver > > 6. Even when there is only one secondary buffer, wine currently mixes it into > primary, possibly with volume and/or sample rate adjustments. Yes, but there is no volume gain/atten when mixing done you should notice about those "FIXME: SetVolumePan" messages in the log > > 8. Your words "it is the Linux system mixer need to support all formats and > rates when mixing" can be equivalently reformulated "it is a bug that wine > itself handles mixing and resampling (including that of secondary dsound > buffers into primary) at all". > No, because none of those linux system mixer can support all sound cards, wine have to provide a fallback in "emulation" mode to provide mixing for those sound cards /dev/dsp does not support mixing for most of the sound cards so wineoss also need dsound to perform software mixing snd-emu10k1 must use "front" device for playback since there is a hook to change the internal routing to different jacks and this is why wineoss suddenly fail to work with SB live! sound cards when using ALSA 's OSS emulation > As for the 24-bit case, well, I am not sure. But the old code also tried to > handle it in convert_??_to_24() and convert_24_to_??() functions, so 24-bit > secondary buffers at least were meant to work. The new code tries to preserve > the existing behaviour. Let's try not to do two things at once (implement both > proper resampling and proper subset of supported formats). We can always rip > out 24-bit support before or later, as it is a different issue than the > zero-order-hold resampler. In other words, I want to see "drop 24-bit support > from dsound" and "replace the zero-order-hold internal resampler with something > else" as separate patches. I think the problem is jack server only support float format , winejack must provide 16bits to float conversion inside winejack for waveoutopen As winejack does not really provide dsound support ( no DSCAPS ) in wine, I have doubt about adding 24bits support to dsound when your test case is using winejack and especially foobar is not an dsound game application -- 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.

Dec. 27, 2010

[Bug 25622] Miranda IM and TabSRMM

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=25622 --- Comment #4 from GrantD <register(a)ciengi.com> 2010-12-26 19:52:46 CST --- Well, I am running Arch Linux, how do I do the debug symbols? Also, to replicate it, install msvcp80.dll and msvcp60.dll into the system32 (if running 32 bit wine) or syswow64 (if running wow64 wine) and start up Miranda with TabSRMM set as the default and open a chat window. -- 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.

Dec. 27, 2010

[Bug 4553] Future Cop doesn't start

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=4553 EoD(a)xmw.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |EoD(a)xmw.de --- Comment #6 from EoD(a)xmw.de 2010-12-26 19:34:47 CST --- (In reply to comment #3) > Is this still an issue in current (0.9.52 or newer) wine? The game still crashes the same way with wine 1.3.8. Also pressing escape, space and even deleting the video folder doesn't change anything. Are you interested in a WINEDEBUG=+all logfile? -- 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.

Dec. 27, 2010

[Bug 25616] Comet Busters: Error displays indicating Wine cannot continue

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=25616 --- Comment #5 from Andrew Nguyen <arethusa26(a)gmail.com> 2010-12-26 18:37:41 CST --- Can you please provide the information I requested? I can't reproduce a crash with Comet Busters! from http://www.fasterlight.com/hugg/projects/cometbusters.html installed in a clean Wine prefix using wine-1.3.10. -- 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.

Dec. 27, 2010

[Bug 25622] Miranda IM and TabSRMM

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=25622 --- Comment #3 from Nikolay Sivov <bunglehead(a)gmail.com> 2010-12-26 18:27:25 CST --- Ok, now install debug symbols package for wine and attach another log with debug information. Also specify some steps to reproduce (what needs to be done after installation to crash it). -- 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.

Dec. 27, 2010

[Bug 14717] resampled sound is horrible

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14717 --- Comment #77 from Raymond <superquad.vortex2(a)gmail.com> 2010-12-26 18:24:08 CST --- (In reply to comment #74) The whole problem is that wine forces the use of its own bad > resampler instead of a resampler from ALSA when an application requests a > secondary DirectSound buffer with a rate different from the default sample rate > configured in winecfg, and the patch attempts to replace this bad resampler > with a better one. Do you know that some sound card can not use dmix since dmix require sound driver provide mmap access ? (i.e. there can be no system mixer for some sound cards ) It is because winealsa.drv provide the mixing of secondary software buffers in the primary hardware buffer (emulation mode) when there is no kmixer This is the difference of dsound in wine and win since you don't even need to set the default sample rate , 8/16 bits data because the kmixer can automatically adjust the reampling rate to the maximum of the playing streams but those system mixer or sound servers in linux cannot This also make the implementation of secondary hardware buffers for those hardware mixing sound cards very difficult since it use up one of the hardware buffer of mixing software secondary buffers Most of those hardware mixing sound cards are also support Wavetable synth, they can provide at least 16 voices for playing midi That is why they have 16 secondary hardware buffers -- 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.

Dec. 27, 2010

[Bug 25622] Miranda IM and TabSRMM

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=25622 --- Comment #2 from GrantD <register(a)ciengi.com> 2010-12-26 18:11:31 CST --- Created an attachment (id=32630) --> (http://bugs.winehq.org/attachment.cgi?id=32630) wine miranda32.exe &> log.txt Sorry, I had the log and forgot to attach it -- 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.

Dec. 27, 2010

[Bug 19873] Automated installation of gecko requires DOS path to root filesystem

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=19873 Jacek Caban <jacek(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #24 from Jacek Caban <jacek(a)codeweavers.com> 2010-12-26 17:37:15 CST --- This bug seems to be fixed for a while now. wine_get_dos_file_name returns "\\?\unix\..." file name in this case and cabinet.dll works fine with it. -- 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.

Dec. 26, 2010