October 2007 - Wine-Devel - list.winehq.org

Re: PulseAudio as a sound output?

by L. Rahyen

On Monday October 8 2007 23:01, TheBlunderbuss wrote: >> L. Rahyen wrote: >> I didn't tested yet my one-core system with new 2.6.23 kernel so >> I'm not sure how well it will behave with uniprocessor system but I guess >> it should work as expected. > Please test with your uniprocessor and get back to us on it. Not all of us > can have the top-of-the-line system. OK. I can test it with my 64-bit Sempron 1.4 GHz on weekend and report results. Unfortunately I cannot test it right now because it is used for important Forex-related tasks so I can test it (or perform any kind of maintenance work) only on weekends. > To all: stay away from Celerons! 128KB L2 isn't enough! I also have 32-bit Celeron 2.8 GHz at home. This computer with Celeron was a gift from a friend for my brother so I didn't spend my money for it (I never going to buy Celerons). And yes, I agree, Celeron is really bad processor so it is really good idea to buy something else if you have a choice...

Oct. 9, 2007

Re: PulseAudio as a sound output?

by King InuYasha

Wine must not let go of the OSS support since OSS was recently made GPL'd and CDDL'd for use in FOSS kernels by its maker (4Front) and OSS is the POSIX audio system of choice for nearly every time except Linux. Linux does not use OSS anymore and uses ALSA. Since Linux is the primary target of Wine, obviously ALSA needs to be well supported. Since under normal conditions ALSA and OSS do horrible mixing and handling of audio (kernel or audio module bug, whatever, its still a problem), I'm betting that was why the ESD and JACK drivers were made. I am not disputing the JACK driver because I recognize that JACK may be necessary for certain tasks. However, the ESD driver should be replaced with something more up to date. I hope that PulseAudio would be that replacement. I don't think I suggested removing the baseline stuff (ALSA and OSS). PulseAudio is what I would consider to be the middle man between JACK and ALSA/OSS. Mainly because it does have some of the upscale features (low-latency, network sound, etc.) and some of the commodity features (superior mixing, multiple audio backend support like ALSA, OSS, and Win32MM, etc.) I believe this balance would help with Wine sound very much. Certainly the new scheduler in Linux kernel 2.6.23 would improve how the kernel/kernel modules handle threading and processing the audio streams, but that wouldn't necessarily help with the baser problems (mixing, stream locks, etc.) though it does help with stuff like stuttering. I also recognize that Alexandre may not want to support so many audio backends. I find only three absolutely necessary, and the fourth one is widely clamored for. The necessary ones are: JACK, OSS, and PulseAudio. The widely clamored one is ALSA. Why? Because ALSA is ENTIRELY Linux specific. Wine is to be a Win32 to UNIX translation layer for compiled applications. If too much focus on being Linux-specific is given, I believe it will mess up general FOSS adoption as a whole. Just my two cents.... :) On 10/8/07, Tijl Coosemans <tijl(a)ulyssis.org> wrote: > > On Monday 08 October 2007 14:43:30 Dave Phillips wrote: > > Well, first I'd suggest simply supporting ALSA as thoroughly as > > necessary or possible. It is the default kernel sound system, Wine > > may as well incorporate it as well as it can. Supporting the > > deprecated OSS API might be a good idea too, through ALSA's > > OSS-compatibility layer. As one devel noted, it may be a good idea to > > forego further development of things like the NAS and ESD servers > > until a more solid basis exists for ALSA/OSS. > > I just wanted to add that OSS isn't deprecated. ALSA is Linux-only. > OSS is a multiplatform solution. > > >

Oct. 8, 2007

Re: PulseAudio as a sound output?

by TheBlunderbuss

Oct. 8, 2007

Re: PulseAudio as a sound output?

by King InuYasha

On 10/8/07, King InuYasha <ngompa13(a)gmail.com> wrote: > > Wine must not let go of the OSS support since OSS was recently made GPL'd > and CDDL'd for use in FOSS kernels by its maker (4Front) and OSS is the > POSIX audio system of choice for nearly every time except Linux. Linux does > not use OSS anymore and uses ALSA. Since Linux is the primary target of > Wine, obviously ALSA needs to be well supported. Since under normal > conditions ALSA and OSS do horrible mixing and handling of audio (kernel or > audio module bug, whatever, its still a problem), I'm betting that was why > the ESD and JACK drivers were made. I am not disputing the JACK driver > because I recognize that JACK may be necessary for certain tasks. > > However, the ESD driver should be replaced with something more up to date. > I hope that PulseAudio would be that replacement. I don't think I suggested > removing the baseline stuff (ALSA and OSS). PulseAudio is what I would > consider to be the middle man between JACK and ALSA/OSS. Mainly because it > does have some of the upscale features (low-latency, network sound, etc.) > and some of the commodity features (superior mixing, multiple audio backend > support like ALSA, OSS, and Win32MM, etc.) I believe this balance would help > with Wine sound very much. > > Certainly the new scheduler in Linux kernel 2.6.23 would improve how the > kernel/kernel modules handle threading and processing the audio streams, but > that wouldn't necessarily help with the baser problems (mixing, stream > locks, etc.) though it does help with stuff like stuttering. I also > recognize that Alexandre may not want to support so many audio backends. I > find only three absolutely necessary, and the fourth one is widely clamored > for. The necessary ones are: JACK, OSS, and PulseAudio. The widely clamored > one is ALSA. Why? Because ALSA is ENTIRELY Linux specific. Wine is to be a > Win32 to UNIX translation layer for compiled applications. If too much focus > on being Linux-specific is given, I believe it will mess up general FOSS > adoption as a whole. > > Just my two cents.... :) > > On 10/8/07, Tijl Coosemans <tijl(a)ulyssis.org> wrote: > > > > On Monday 08 October 2007 14:43:30 Dave Phillips wrote: > > > Well, first I'd suggest simply supporting ALSA as thoroughly as > > > necessary or possible. It is the default kernel sound system, Wine > > > may as well incorporate it as well as it can. Supporting the > > > deprecated OSS API might be a good idea too, through ALSA's > > > OSS-compatibility layer. As one devel noted, it may be a good idea to > > > forego further development of things like the NAS and ESD servers > > > until a more solid basis exists for ALSA/OSS. > > > > I just wanted to add that OSS isn't deprecated. ALSA is Linux-only. > > OSS is a multiplatform solution. > > > > > > >

Oct. 8, 2007

Wine's wikipedia article sucks

by Scott Ritchie

The current article for Wine is here: http://en.wikipedia.org/wiki/Wine_%28software%29 It needs a lot of work. There's a large (and growing) todo list on the talk page: http://en.wikipedia.org/wiki/Talk:Wine_%28software%29 Some of the information needed (eg, statistics for Wine usage) are likely unavailable to the average wikipedian, so we Wine experts might need to help directly. I'm pretty sure a good wikipedia article, with proper links and explanations, would cut down significantly on the amount of user misinformation about Wine. Fixing the wikipedia article might do more for usability than actually improving the software. Thanks, Scott Ritchie

Oct. 8, 2007

request for kernel32/toolhelp windows testrun

by Marcus Meissner

Hi, I have a game (Last Chaos USA by AeriaGames) which does not start up the main game due to a bug in its toolhelp snaphot handling. It does: h = CreateToolhelp32Snapshot(); Process32First(h, &x); while (Process32Next(h,&x)) { /* check x */ } So it discards the very first entry we return from the snapshot. However it is looking for itself here and in current Wine it is in the first entry, ... so failure. So I reorder the list to be backwards and it works better then. BUT I would like to test run it on windows first, so can someone please run following patch against a real Windows? Thanks & Ciao, Marcus diff --git a/dlls/kernel32/tests/toolhelp.c b/dlls/kernel32/tests/toolhelp.c index ca9c06c..f135abb 100644 --- a/dlls/kernel32/tests/toolhelp.c +++ b/dlls/kernel32/tests/toolhelp.c @@ -108,6 +108,7 @@ static void test_process(DWORD curr_pid, MODULEENTRY32 me; unsigned found = 0; int num = 0; + int pos1 = -1 , pos2 = -1; hSnapshot = pCreateToolhelp32Snapshot( TH32CS_SNAPPROCESS, 0 ); ok(hSnapshot != NULL, "Cannot create snapshot\n"); @@ -118,8 +119,8 @@ static void test_process(DWORD curr_pid, { do { - if (pe.th32ProcessID == curr_pid) found++; - if (pe.th32ProcessID == sub_pcs_pid) found++; + if (pe.th32ProcessID == curr_pid) { pos1 = num; found++; } + if (pe.th32ProcessID == sub_pcs_pid) { pos2 = num; found++; } trace("PID=%x %s\n", pe.th32ProcessID, pe.szExeFile); num++; } while (pProcess32Next( hSnapshot, &pe )); @@ -141,6 +142,9 @@ static void test_process(DWORD curr_pid, ok(found == 2, "couldn't find self and/or sub-process in process list\n"); ok(!num, "mismatch in counting\n"); + ok (pos2 == 1, "new process at position %d in snapshot, expected 1.\n", pos2); + ok (pos1 == 0, "this process at position %d in snapshot, expected 0.\n", pos1); + te.dwSize = sizeof(te); ok(!pThread32First( hSnapshot, &te ), "shouldn't return a thread\n");

Oct. 8, 2007

Re: Moving the wine status pages to the wiki

by Scott Ritchie

Kai Blin wrote: > Hi folks, > > I'm currently looking into getting an up-to-date list of maintainers for > certain subsystems. I would like to keep that in the context of the dll status > pages, but in order to keep them maintainable, I'm considering to move those > pages to the wiki. > > Any thoughts about that? > Moving the FAQ to the wiki worked phenomenally well. Go for it. Thanks, Scott Ritchie

Oct. 8, 2007

Re: PulseAudio as a sound output?

by Tijl Coosemans

On Monday 08 October 2007 14:43:30 Dave Phillips wrote: > Well, first I'd suggest simply supporting ALSA as thoroughly as > necessary or possible. It is the default kernel sound system, Wine > may as well incorporate it as well as it can. Supporting the > deprecated OSS API might be a good idea too, through ALSA's > OSS-compatibility layer. As one devel noted, it may be a good idea to > forego further development of things like the NAS and ESD servers > until a more solid basis exists for ALSA/OSS. I just wanted to add that OSS isn't deprecated. ALSA is Linux-only. OSS is a multiplatform solution.

Oct. 8, 2007

Re: PulseAudio as a sound output?

by Adam Petaccia

On Sun, 2007-10-07 at 23:07 +0200, Michael Stefaniuc wrote: > Hello! > > King InuYasha wrote: > > I would like to suggest that eventually Wine would support PulseAudio as > > a sound output natively. I am already aware of Wine supporting ESD, > > which PulseAudio can use, but supporting PulseAudio natively I think > > would be much better. > There are already a couple too many sound drivers in Wine and none of > which are great. Alexandre won't accept yet another sound driver in > Wine. He would like to have one sound driver working perfect (probably > winealsa). > I'm not a developer, but I think Pulseaudio would be great for wine, not becuase its "just another sound server" (which it can be viewed as) but allows more complex configurations to be set up, because Pulseaudio is a very good sound _mixer_, which allows the user (if he/she wishes) to do some pretty cool thing regarding audio input and output. Although I understand this isn't a high priority (shouldn't block Wine 1.0), it would be nice to have in 1.1 or 1.2 > bye > michael

Oct. 8, 2007

Re: PulseAudio as a sound output?

by L. Rahyen

On Monday October 8 2007 10:48, Maarten Lankhorst wrote: > Damjan Jovanovic schreef: > > Pulseaudio isn't "yet another sound server", it's a full-blown > > replacement for all other sound servers. It mixes sound better than > > alsa's dmix, it's a drop-in replacement for ESD, and it works even for > > OSS applications using oss2pulse. Some of its interesting features > > include per-application volume levels, RTP multicasts, the ability to > > embed it within an application instead of running a separate server, > > and a Windows port. > > > > The reason it would be good for wine is because it (optionally) runs > > in realtime (SCHED_RR) priority, and is designed for low-latency > > playback. Even wine's latest alsa driver continuously stutters under > > high CPU load (play back some music with foobar2000, while searching a > > large PDF). > > That's not the fault of our audio driver, it is because of linux doing > bad things with i/o scheduling. For whatever reason as soon as a wine > blocks on i/o all other threads get cpu starved. This is not a wine bug, > but a linux bug. You probably should try new linux kernel. There is high chances that it will fix these problems for you. Personally I use 2.6.23-rc8. You find that with new kernel performance is very good even under heavy load. Maybe someone here will be interested in hearing my story with these problems (maybe you find good advice in it; besides it is about WINE related issues)... If you don't like long personal stories then you can skip rest of this message and just try 2.6.23. Just a note: when I refer to "performance" in this message I mean fairness, smoothness and efficiency of CPU sharing between processes under high average loads not wall-clock execution time. Many years ago I switched to Linux. And everything was great but performance under heavy load was very poor. Windows performance under heavy load is much worse but this doesn't make Linux performance better (please note here that I'm talking about very old Linux versions - 2.4.x kernel series!). For example when I tried to launch game with WINE during heavy load (rendering, video encoding, etc.) game was completely unplayable; even setting nice of -20 for the game and 19 for other processes doesn't help: both game and other processes loses too much performance. After some time because Linux is open source I decided to try to fix this somehow. At that time I used 2.6.x kernel series. First I tried to adjust some parameters in the kernel scheduler, then did some other modifications - and get acceptable performance even under heavy load! In fact it was possible to play game in WINE even if I have high load and high I/O to disk. Unfortunately my modifications was just a hack. I never found enough time to make a correct fix. But my modifications was stable and worked well for me. My brother likes to play games and I like to run 3D-rendering, scientific calculations, etc. (this is exactly why I have 24 hours per day heavy load almost always so it is important to be able to run games simultaneously especially for my brother). And of course no problems with audio latency anymore... After some years I decided to try some non-standard schedulers but most of them was much worse than my hack for standard scheduler. However, scheduler from ck patch-set have some good features in it. Unfortunately performance is worse with it than with my hack for vanilla scheduler so I did some modifications to ck scheduler and get very good kernel which works even better under heavy loads - in fact, really perfectly. With this kernel I was able to run games absolutely smoothly even when I have few background processes with big CPU usage (on one-core system!). It should be clear that "more background processes you have less FPS you get" in CPU limited game; only important thing here is that CPU sharing should be fair and smooth, and should respect niceness correctly. But when I have purchased 3 GHz quad-core system with 8 GiB of RAM I (again!) found big problems with fairness of CPU sharing... Even with my kernel with modified scheduler from ck patches which works very smoothly on one-core system I have really bad performance under heavy load on SMP system - this is strange because I expected better performance with quad-core system! But no, it was bad. Instead of trying to fix this myself I decided to try experimental 2.6.23-rc3 Linux kernel with new scheduler. And now, finally, I have good performance even under heavy load on my system with standard Linux kernel! I can copy big files, run multi-threaded scientific calculations in background (with total average load of about 6-12 or more) and play 3D-games in WINE simultaneously on my quad-core system. In past I was able to get same smoothness only on one-core system with my "evil hacks" and ck patch-set as I described above (with uniprocessor system instead of 6-12 load I have tested with 2-5 load). I didn't tested yet my one-core system with new 2.6.23 kernel so I'm not sure how well it will behave with uniprocessor system but I guess it should work as expected. So as you can see trying 2.6.23 kernel is really good idea if you don't like standard scheduler in older Linux kernels (or you can wait for stable 2.6.23 release if you don't want to compile kernel yourself). Final conclusion for this topic is simple: if you have problems with audio only under some kind of heavy CPU load this isn't fault of WINE or ALSA. And now you can try new Linux kernel, it may help to resolve these problems. You can read about new scheduler in the 2.6.23 kernels here: http://www.linuxinsight.com/cfs-scheduler-to-appear-in-linux-kernel-2.6.23.…

Oct. 8, 2007