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.
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.
Audio in wine is still a problematic area. The situation is already horrible because we have to go through several layers. Sound servers are an additional layer on top of lets say oss, alsa or other APIs. Alsa on its own is already very complicated to get working. A sound server will add more latency and so on. From a wine point of view what you need to use is Alsa and make that work correctly with pulseaudio. I think that some day in the near future we might even drop esd and some of the other drivers because they are a hell to get working and to maintain them. Roderick -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
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).
bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 -------------------------------------------------------------------- Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart Handelsregister: Amtsgericht Stuttgart HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich
On 10/7/07, Michael Stefaniuc <mstefani(a)redhat.com> 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).
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).
bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111
Damjan Jovanovic
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. I'm not in favor for yet another half supported sound system, I would rather have our own sound systems working better. Can't you just use forwarding from JACK or something? Cheers, Maarten.
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.
I'm not in favor for yet another half supported sound system, I would rather have our own sound systems working better. Can't you just use forwarding from JACK or something?
Greetings, I'm not a Wine devel, but I am closely allied with the Linux audio community (yes, there is such a thing) and I use Wine frequently for running Windows ASIO-based music and sound apps. I use Robert Reif's wineasio driver, which basically does what Maarten would like to see. IMO the Wine/Linux audio problem stems from the very different primary uses of sound: normal audio/video playback (CD, DVD, streaming A/V, etc), games, and desktop/studio audio production. Each of these uses has its own needs and expectations. Normal playback and game use wants surround and 3D sound support, along with the ability to not interfere with other audio processes (software mixing). Pro-audio usage needs low-latency and zero dropouts. JACK would seem to be the best-case solution (wineasio depends on it), but I fear it's overkill for the normal user. Also, it's not a default feature in most Linux distros (excepting of course the multimedia-optimized ones such as 64 Studio, JAD, Planet CCRMA, Musix, dynebolic, etc). The esd and artsd servers are not designed for low-latency and other pro-audio specs, so while they'll work for normal use they are unsuitable for serious production. So yes, there's a problem. Can there be a one-size-fits-all solution ? 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 also urge any Wine audio development to stay in touch with general developments in Linux audio. The wineasio driver is already good enough to draw some Windows users into the fold. That driver gives them low-latency close to native performance (i.e. with ASIO), and a variety of Windows sound and music apps can now be run in a production capacity. The issue of VST support is a show-stopper for many musicians who would like to switch platforms. For a while, the FST project provided a nice bridge that allowed running VST/VSTi plugins as standalone programs, but a long-standing X-related bug (since at least the 0.9.3x series) has gutted FST's capability. So at this time, if a user wants to use VST plugs he can either use FST with an older Wine, or he can use a new version with the wineasio driver. Btw, both solutions depend on JACK. A bit of a ramble, but I hope I've made my point. Sound support in Wine is an important aspect of its development, and many users are currently thwarted in their attempts to leave Windows simply because their favorite sound-apps can't be run in Wine. I don't expect to see Cubase or Logic running under the system any time soon, but it would be a cool thing to look forward to eventually happening. :) Best regards, Dave Phillips
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.
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.
I agree that wineoss needs to remain. I don't remember anymore if there was still some reason for keeping wineesd. Both jack and pulseaudio can provide alsa support for applications. So in principle there is no reason for direct support in wine for either of them. We might be able to get trough with also removing winejack and winenas. winejack could be replaced with either wineasio (which uses jack directly) or with winealsa -> jacks alsa plugin. The main use case for winenas is network audio in a thin client environment which I assume is also supported by pulseaudio where we again can use winealsa -> pulseaudios alsa plugin. Jan
While PulseAudio can work through ALSA, it makes you lose the finer grains of control over audio when it is sent through ALSA to PulseAudio. It is also redundant in most cases, since PulseAudio generally will be connected to localhost to ALSA on localhost, so it is not very smart to rely on winealsa to connect to PulseAudio. the wineesd component could be replaced with a winepulse component (just made up the name, winepulse) that would support the finer grains of control in the audio server. Stuff like the application based mixer could be handled through winepulse and allow Wine to control only its own audio stream. That way, there isn't a conflict between audio streams to send to audio output. Sending audio output through ALSA/OSS to any audio server is basically redundant and pointless. Sending to the Audio Server to ALSA/OSS is better. On 10/9/07, Jan Zerebecki <jan.wine(a)zerebecki.de> wrote:
I agree that wineoss needs to remain.
I don't remember anymore if there was still some reason for keeping wineesd.
Both jack and pulseaudio can provide alsa support for applications. So in principle there is no reason for direct support in wine for either of them.
We might be able to get trough with also removing winejack and winenas. winejack could be replaced with either wineasio (which uses jack directly) or with winealsa -> jacks alsa plugin. The main use case for winenas is network audio in a thin client environment which I assume is also supported by pulseaudio where we again can use winealsa -> pulseaudios alsa plugin.
Jan
On Wed, Oct 10, 2007 at 06:22:19PM -0500, King InuYasha wrote:
While PulseAudio can work through ALSA, it makes you lose the finer grains of control over audio when it is sent through ALSA to PulseAudio.
Then it seems that is a limitation of the alsa plugin pulseaudio provides. Fixing that plugin would not only benefit Wine when it uses pulseaudio through alsa but every application which might do this. Implementing a winepulseaudio would only bring that benefit to Wine and it would have to be duplicated for every other alsa application which pulseaudio would want to support.
It is also redundant in most cases, since PulseAudio generally will be connected to localhost to ALSA on localhost, so it is not very smart to rely on winealsa to connect to PulseAudio.
Sending audio output through ALSA/OSS to any audio server is basically redundant and pointless. Sending to the Audio Server to ALSA/OSS is better.
I guess you didn't want to say that the audio is sent over ip. Though I don't know how pulseaudio does things specifically, I do know what is technically possible. Passing data from one process to another on the same computer can be done without copying the data. Also passing the data into the alsa library which passes it into the hardware or dmix or the pulseaudio plugin does not involve two steps as you seem to suggest, but only one. Yes alsa->pulseaudio is an additional layer but you could think of it as a replacement of pulsaudio-api->pulseaudio.
That way, there isn't a conflict between audio streams to send to audio output.
Any mixing resolves this conflict, the only thing that does not support this is bare oss. Jan
On Thursday 11 October 2007 04:02:22 Jan Zerebecki wrote:
On Wed, Oct 10, 2007 at 06:22:19PM -0500, King InuYasha wrote:
That way, there isn't a conflict between audio streams to send to audio output. Any mixing resolves this conflict, the only thing that does not support this is bare oss.
I think OSSv4 does. Multiple applications can open the same device and the audio streams will be mixed.
On Thu, Oct 11, 2007 at 11:44:03AM +0200, Tijl Coosemans wrote:
On Thursday 11 October 2007 04:02:22 Jan Zerebecki wrote:
On Wed, Oct 10, 2007 at 06:22:19PM -0500, King InuYasha wrote:
That way, there isn't a conflict between audio streams to send to audio output. Any mixing resolves this conflict, the only thing that does not support this is bare oss. I think OSSv4 does. Multiple applications can open the same device and the audio streams will be mixed.
i used a very long time oss only with my emu10k card and i never had to use anything else beside - it just worked with everything i did. the pita started since i used alsa (e.g. with software like mumble). -- cu
Hello Dave, Dave Phillips schreef:
I'm not a Wine devel, but I am closely allied with the Linux audio community (yes, there is such a thing) and I use Wine frequently for running Windows ASIO-based music and sound apps. I use Robert Reif's wineasio driver, which basically does what Maarten would like to see.
IMO the Wine/Linux audio problem stems from the very different primary uses of sound: normal audio/video playback (CD, DVD, streaming A/V, etc), games, and desktop/studio audio production. Each of these uses has its own needs and expectations. Normal playback and game use wants surround and 3D sound support, along with the ability to not interfere with other audio processes (software mixing). Pro-audio usage needs low-latency and zero dropouts.
Games do too, however it stays a compromise between low latency and a risk of dropouts. The dropouts are caused by the kernel, you could slightly tweak it, and get it down to ~70ms, but more isn't possible without tweaking dmix to use 512 frames in a period instead of 1024, or direct hardware access.
JACK would seem to be the best-case solution (wineasio depends on it), but I fear it's overkill for the normal user. Also, it's not a default feature in most Linux distros (excepting of course the multimedia-optimized ones such as 64 Studio, JAD, Planet CCRMA, Musix, dynebolic, etc). The esd and artsd servers are not designed for low-latency and other pro-audio specs, so while they'll work for normal use they are unsuitable for serious production. So yes, there's a problem. Can there be a one-size-fits-all solution ?
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.
That's what I've been trying, I hope I succeeded. There are still some problems with directsound, but there are few things left I can do about those.
I also urge any Wine audio development to stay in touch with general developments in Linux audio. The wineasio driver is already good enough to draw some Windows users into the fold. That driver gives them ´ low-latency close to native performance (i.e. with ASIO), and a variety of Windows sound and music apps can now be run in a production capacity.
I have nothing against incorporating wineasio, as long as you can get someone to maintain it once it's in, rather then let it slowly bitrot away, but if wineasio and winejack do the same, it would make sense to make 1 of the 2 go.
The issue of VST support is a show-stopper for many musicians who would like to switch platforms. For a while, the FST project provided a nice bridge that allowed running VST/VSTi plugins as standalone programs, but a long-standing X-related bug (since at least the 0.9.3x series) has gutted FST's capability. So at this time, if a user wants to use VST plugs he can either use FST with an older Wine, or he can use a new version with the wineasio driver. Btw, both solutions depend on JACK.
Have you considered filing a bug report, and do a regression test? It's easy to do and would allow you to find the exact cause of the glitch, and if it's obvious you could even fix it yourself.
A bit of a ramble, but I hope I've made my point. Sound support in Wine is an important aspect of its development, and many users are currently thwarted in their attempts to leave Windows simply because their favorite sound-apps can't be run in Wine. I don't expect to see Cubase or Logic running under the system any time soon, but it would be a cool thing to look forward to eventually happening. :)
I agree. Cheers, Maarten
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.h...
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...
On Monday October 8 2007 23:01, TheBlunderbuss wrote:
L. Rahyen wrote: Please test with your uniprocessor and get back to us on it. Not all of us can have the top-of-the-line system. To all: stay away from Celerons! 128KB L2 isn't enough!
Sorry for a big delay in reply. In practice it is very difficult for me to test anything on my server (because as I said it used for tasks related to forex and therefore I only can test something on weekends; this is sometimes is difficult too because currently I have a lot of work at weekends too unfortunately). I wasn't able to do full tests (compare different kernels, test all typical situations, etc.) because of lack of time and therefore I cannot post exact numbers to compare, sorry. But I post at least my impressions related to work of old uniprocessor system with 2.6.23 kernel. Well, everything is good. At least it seems to me that now everyone can forgot about sound issues when system is under heavy load: sound is clean even if I have a lot of working processes in background (I tested up to 10 - that's more than enough for uniprocessor system I think). I tried processes with and without heavy disk I/O - and sound was perfect. However, new scheduler isn't so perfect as it may seems at first glance. There is some issues with fairness anyway. And there is still no option to select frequencies higher than 1 KHz in vanilla kernel (this is sometimes useful for uniprocessor systems). I didn't run benchmarks so I cannot be sure but I think that my 2.6.22 kernel with some patches and hacks to the scheduler worked somewhat better, more smoothly under heavy load. Yes sound is clean and good but some applications doesn't run as smooth as I expect even with -20 niceness under heavy load (on my quad-core processor there is no such problem). Unfortunately I didn't test OpenGL (and games) in my uniprocessor system with 2.6.23 kernel because of annoying bug in NVidia driver which happens sometime on this old machine: I have less than 1 FPS everywhere and only way to "fix" this is to reboot the machine (or reload the driver manually but this isn't working in all cases and require to shutdown X servers anyway). There was Sunday and about 20:00 GMT so I simply havn't time to test farther because after 21:00 GMT server should start its usual servicing. But even without any benchmarking I can say that 2.6.23 contain very big improvement in Linux scheduler. If you compare it with vanilla 2.6.22 or older (without any hacks and modifications to the scheduler) you will see that now many thing works perfectly even on uniprocessor system. As I have said before SMP systems have especially noticeable improvements. Now 2.6.23 is stable so everyone can easily try and test it. All major distribution should provide precompiled 2.6.23 kernels in near future.
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 King InuYasha schreef:
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.
This is something I was working on a couple of months ago. I got some beeps out of the driver I wrote, and foobar2000 was even able to play music as long as I didn't touch any of the playback controls. :) But I never got around to finishing it. And in it's current state it can't really do any serious work, afaik. If someone else wants to pick it up, I'd be happy to publicly embarrass myself and post the code here. (If I can still find it. :o) As a side note, the only other driver that seems to work right on top of PulseAudio's emulation is the OSS driver. I play Worms Armageddon using that without too many issues. - -- Stéphan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHEfaacFUq0gzqDwQRAtc5AJ98g/q/U6MMjH8FvUveUkzvpo7AtwCfULCR xH0ZiKKbmQ/gTo5vUHcAyPw= =nGSr -----END PGP SIGNATURE-----
participants (13)
-
Adam Petaccia -
Christoph Frick -
Damjan Jovanovic -
Dave Phillips -
Jan Zerebecki -
King InuYasha -
L. Rahyen -
Maarten Lankhorst -
Michael Stefaniuc -
Roderick Colenbrander -
Stéphan Kochen -
TheBlunderbuss -
Tijl Coosemans