I've seen several things stating that Wine will never add another audio sink and pulseaudio integration will never happen. This annoys me for two reasons. 1. pulse isn't going away, at least within the next 5 years. 2. There's a working (shockingly well) patch just begging to be brought into the trunk: http://art.ified.ca/?page_id=40 Has there been any thought on implementing this fairly simple patch? It would certainly get my +1 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.winehq.org/pipermail/wine-users/attachments/20090926/9d24538c/attachment.htm>
On Sat, Sep 26, 2009 at 11:00, Oli Warner <oli at thepcspy.com> wrote:> This annoys me for two reasons. > ? 1. pulse isn't going away, at least within the next 5 years. > ? 2. There's a working (shockingly well) patch just begging to be brought > ? into the trunk: http://art.ified.ca/?page_id=40 > > Has there been any thought on implementing this fairly simple patch? ItAccording to what was said here and on wine-devel that patch is ugly... It was also said that a proper libpulse plugin (The WinePulse patch seem to be an ugly hack based on the alsa plugin) might be accepted, search the archives... Random question: How does the Windows version of PulseAudio work? Is is capable of intercepting audio from existing applications? And if it is, is it capable of running under Wine? Non-pulse Win32/64 Application > Windows pulse > Linux pulse might be a really elegant solution, potentially requiring no changes in Wine? Not sure if this is a "no"? http://www.pulseaudio.org/wiki/FAQ#IsthereaWin32WindowsdriverthatactlikeaPulseAudioclient Gert
Oli Warner wrote:> IHas there been any thought on implementing this fairly simple patch?Read the bug it has lots of reasons why it's not included in Wine.
Simple fact here Oli Warner it is not that another audio out will not be added. Each added audio sync makes maintaining the audio system of wine harder. Most valid item in the current Linux world to add to wine is not pulseaudio. If you want a better support for pulseaudio support for a gstreamer audio out to be added. Reason gstreamer would allow alsa oss jack.... sections of code to be dropped from wine and the responsibility for interfacing with audio be transferred to gstreamer. This is simplerify the audio system. Current wine audio stack is already too complex.
Basically that is no Gert The windows catch for pulseaudio is in a worse state than pulseaudio support for alsa. http://userweb.kernel.org/~tj/ossp/ Will be usable in the next 12 months so OSS works. Basically there is no reason to support pulseaudio either OSS out or ALSA out will do the job. Thinking that all ALSA drivers are also char devices there are a lot of open chances to rip out both OSS and ALSA now.
Meh, I'm not sure how it is done nowadays, but wouldn't it be easier to just have a base abstract class which defined pure virtual functions with all the methods that Wine needed- Then each one of the individual sound drivers could inherit from that class and wine could use a simple polymorphic approach. This is how I've always imagined things like those to be made. But, then again, I understand it might be much more complex than that...and that Wine may be alergic to C++. Cheers, Jorl17
Oli Warner wrote:> And for the record, I'd be more than happy to use ALSA on top of PA (or directly if it didn't need me to pasuspend) but it doesn't "just work".Used to, before PA came about. This clearly points that something isn't right about it. Get rid of PA (not disable, remove completely) and bingo - Wine's sound starts working again. If you say "app X requires PA" - recompile it without PA, all those apps still support ALSA/OSS. Ubuntu been hard at work for number of years breaking Wine every other way they can find. Ask them to get their act together and stop this practice. At least testing their new releases with Wine and fixing _major_ issues will be nice of them.
On my Fedora 11 Pulse broke not only wine, but Amarok and VLC. I might never have discovered the cause if these forums hadn't advised me to get rid of it.
Oli Warner read http://userweb.kernel.org/~tj/ossp/ That is a perfect oss interface emulation. No some half screwed up hack job. Yes we are aware that Wine is part of a bigger ecosystem. This is the reason not to go Pulseaudio but go gstreamer. Lets say Wine supports Pulseaudio directly. Wine developers will have to maintain support for Pulseaudio so using up important development resources. Now what if another sound server appears to replace Pulseaudio. Wine developers have learnt there leason esound at one point was going to be all and end all same with arts and the 30 other sound servers that have existed. Pulseaudio will most likely go the same way be around for awhile until people get sick of it. Now look at gstreamer. Support for gstreamer could allow wine to drop support for Alsa and OSS and share audio driver maintenance with everyone on gstreamer. So integrating wine into the bigger ecosystem. There is no valid reason to support Pulseaudio driver in wine ever. Now remember gstreamer contains a Pulseaudio driver already same with every other sound server and sound interface system in existence on all platforms. Major advantage of going the gstreamer path in wine developers would no longer be on there own maintaining a Audio driver.
Vitamin is right OliWarner. Lot less applications work with Pulseaudio driver for wine than using http://userweb.kernel.org/~tj/ossp/ to send the wine oss driver up into Pulseaudio. Basically there is no point to the pulseaudio driver since there are other ways to get better results. Gstreamer is currently being worked on being added to add codec support to wine direct show support. It also why its advisable if wine goes any way to be gstreamer. Gstreamer will already become a dependency to do other tasks so swaping sound system to gstreamer would allow droping dependancies not adding any. Currently the codec support is the most critical thing for wine to get from Gstreamer. This is number of applications working thing. The developer working on the codec support has interest in developing a low level sound out for the simple issue. If all sound is going threw Gstreamer it can manage it avoiding broken audio. Gstreamer is design to allow it to be able to be shipped in distribution or out of distribution so for a LSB application if had version problem wine could ship own. Personally I hate Pulseaudio. To my mind resource management is the job of the Kernel. X11 made this same mistake of managing resources in user space to stack so problems. The kernel can enforce the only 1 management system that can not be bypassed. What happens if something connects to audio out before pulseaudio yep no sound. Pulseaudio design has the same flaw of all sound servers the bipass and screwed issue. I am not saying that Pulseaudio interfaces are bad. Design is bad it connected in the wrong place.
oiaohm wrote:> Vitamin is right OliWarner. Lot less applications work with Pulseaudio driver for wine than using http://userweb.kernel.org/~tj/ossp/ to send the wine oss driver up into Pulseaudio. Basically there is no point to the pulseaudio driver since there are other ways to get better results. > > Gstreamer is currently being worked on being added to add codec support to wine direct show support. It also why its advisable if wine goes any way to be gstreamer. Gstreamer will already become a dependency to do other tasks so swaping sound system to gstreamer would allow droping dependancies not adding any. >On many distros (like Fedora and Ubuntu), which means tons of users, Gstreamer is now connected to PulseAudio as default backend.
Ossp is not a kernel patch. Ossp is userspace and depends on a kernel feature cuse(char devices in userspace) Cuse appears in 2.6.32 kernels end of year kernel release. Ubuntu 10.10 release cuse will be a default feature no kernel building required. Same with every distribution using 2.6.32 and later kernels. No point wasting effort for something that is only going to be useful for a few months. ossp is very much the windows user space sound server model. Kernel supported interface that all applications talk to. No direct api to sound server no bipass. Windows has a userspace sound server Oli Warner a kernel backed userspace sound server. So applications cannot bypass it and there only can be 1 at any 1 time. I should have been more correct all sound servers on Unix/Linux/BSD have had the defect of being bipassable by design. There is a correct way to build a perfectly stable sound server and a incorrect way. Pulseaudio is the incorrect way. Since it is the incorrect way at some point it will have to be replaced. As long as it does not take 20 years of glitches for developers to get around to doing it. Basically if you stay with pulseaudio you are always going to have glitches from time to time until they address the interface issue. For wine to support Pulseaudio directly you have to prove to us that its not a defective design that we will have to do a new driver in future. Pulseaudio poor ALSA and OSS support has caused issues. They complain about ALSA yet they don't see adding more layers away from kernel is not improving issue. ALSA also containes a sound server in libasound that also could be bypassed because its also in the wrong place. One of the ways to screw Pulseaudio up massively is enable dmix in ALSA under pulseaudio so doubling up sound servers so leading to broken up audio. Pulseaudio has made audio debuging more complex. Should we be happy no. We want simpler audio stack with less glitch causes. Less glitch causes means don't stack the bugger like Pulseaudio has. Pulseaudio is a poor design. A echo of many poor designs. How many times do we have to repeat. You and thousands. Ok thousands used artsd that is dieing and will disappear. Thousands used esound that is basically dead. Thousands uses NAS that is dead. Sorry Thousands even millions means nothing long term. If the design is bad it will die in time when something better comes along. This is how open source works. I have been around long enough to see sound servers come and go. The question for us is not if Pulseaudio is dead man walking. Its how long before we get to write up its tomb stone when something better appears. I work with the audio team of the Linux Standard Base. And sorry my statements hold weight for closed source applications and open source applications that are not distribution bundled and distribution bundled. I most likely hold more weight in my own right than then any single distribution audio team. What is selected by LSB sets advisable path for application developers. Yes I effect upstream of Distributions. Pulseaudio API are excluded from being able to be included into LSB due to its design issue. Gstreamer is on the consideration list it don't have design issues. Don't be foolish again Oli Warner lot of us here are not low level people.
Not critical because we are taking a longer view than you Oli Warner. Many sound servers have been included in wine no more. Wasted many man hours that wine cannot get back. For the time being pulseaudio can be removed from systems. That is a good enough patch for 7 months or people like you could decide to run 2.6.32 kernel when it gets released in December this year only 2 months off with cuse provided. By the time Ubuntu is releasing most of the issue will be gone. Already distributions like fedora ship with cuse enabled. So not every distribution with pulseaudio is blocked from using the Ossp solution now. You could also choose to swap to a distribution that includes cuse. Basically we are in transition to the cuse solution by all distributions so we don't need to do a thing. Ubuntu might pick it up earlier if users request cuse support. That Pulseaudio is going to become a tombstone there is less importance to us to waste time on it. History is important we have wasted time fixing stuff we should have just let go threw to keeper. Something you don't know is wine alsa driver contains work around for pulseaudio issues due to pulseaudio faults in the alsa interface. So why split effort. Some issues are pulseaudio internal changing to direct pulseaudio interface will not cure. There is no point us splitting development. Lets say we add the pulseaudio driver. Coders would have to split there time between OSS ALSA and Pulseaudio so leading to poorer quality of output for all.
I also missed something important. Wine wants to be LSB compadible at some point in future so one binary can install everywhere. Adding a bit of junk like pulseaudio will not help to get to the LSB ends.
There are some uses for wine that are critical for the disabled, and one is Dragon NaturallySpeaking speech recognition, which requires near-zero-latency and crystal-clear incoming sound. People with limited mobility are usually glad to swap any combination of features to get this. On this basis I have objected to Pulse as a mandatory feature in both Ubuntu and wine. DNS reacts to even the small added latency produced by pulse in very bad ways.
Oli Warner <oli at thepcspy.com> wrote about Pulse Audio on October 1, 2009:> >oiaohm, I'm bored of this.There are many of us out here that are too. 1. Pulseaudio is broken. It has broken many folks in seriously bad ways. 2. There are better ways to handle audio. ALSA is one, OSS is another. These WORK folks. I don't know what Pulse is trying to do, but it is just another layer that is not needed for most folks. 3. Supporting ONE and only ONE audio method allows folks to put efforts elsewhere that gets more 'bang for the buck'. So this leads to what we should support: ALSA and OSS. That is it in a nutshell. Maybe if gstreamer becomes mainstream then we should support it as well. Pulse, OpenAL and the rest maybe a waste of time. BTW, the pulse patch adds serious brokenness to Wine from what I read here. Please do not push this any further.>I'm asking for a patch to be applied. Not a maintained audio branch, just a >simple temporary* stop-gap to get the pulseaudio sufferers through. If ossp >is going to save us all within the next 7 months, I'm truly glad for it and >truly look forward to using it..AJ, the code maintainer has said, repeatedly, NO. His word is LAW for this project. He is not, nor will not, change on this. Thus this patch will NOT be incorporated into the Wine Trunk. Not today, not tomorrow, NEVER. Get it?>Susan: I understand what you're saying but I'm not asking for it to be >forced on people, just be there for those that need it.Pulse, when installed and running, breaks what Susan needs. This is contra to the spirit of this project and FOSS. We need to support ALL users with the functionality that works. Please keep in mind that I have years of experience working with software. Pulse is being shoved down people's throats, even though people do not want, desire or need it. This is bad practice. James McKenzie
Oli Warner wrote:> On Thu, Oct 1, 2009 at 5:45 PM, James Mckenzie > <jjmckenzie51 at earthlink.net>wrote: > > > > I don't know what Pulse is trying to do > > > > > > Indeed. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://www.winehq.org/pipermail/wine-users/attachments/20091001/6d787290/attachment.htm>If you so badly want to have it included and want it to be shared, maintain a set of Wine releases with that patch -- simple, although not recommended.
-----Original Message----->From: jorl17 <wineforum-user at winehq.org> >Sent: Oct 1, 2009 11:26 AM >To: wine-users at winehq.org >Subject: [Wine] Re: Pulseaudio > > >Oli Warner wrote: >> On Thu, Oct 1, 2009 at 5:45 PM, James Mckenzie >> <jjmckenzie51 at earthlink.net>wrote: >> >> >> > I don't know what Pulse is trying to do >> > >> > >> >> Indeed. > > >If you so badly want to have it included and want it to be shared, maintain a set of Wine releases with that patch -- simple, although not recommended. >There should be one on repo.cz. However, I cannot get to this site through my ISP to confirm that one exists. Also, we really should concentrate on a solution for gstreamer which appears to be a stable release that is not causing problems with users. Plus, Pulseaudio will not be incorporated into MacOSX per Apple. Alsa/OSS might be already. James McKenzie
Oli Warner oiaohm is my universal handle. To me its equal to my full name just as blunt. I class not using a persons full Author name as a insult also can cause havoc if there were like two people name Oli in here. My personal policy does not change every response everywhere has been handle or name. Note there is more that one Peter Dolding online my handle solved the conflict on reports. Reason for me needing a new kind of online name. If you really want to get formal with my handle. oiaohm is Ok I Am Over Here Mate its only fair that you know it. By the way Oli Warner asking for something to be included in a open source project is very formal. You must prove you self in a formal way. Problem here including Pulseaudio to be removed latter will break one of wine golden rules. The rule is: No hacks. Either implement correctly or not at all. So a temporary/stop-gap solution is not possible. Note correctly in wine include replicating windows flaws and test cases to prove code is correct. Putting code in wine is not just because some fells like it. Wine use to operate that way. Back when every patch to make application work was included wine was making no progress regression after regression. Note the golden rule is not AJ rule. Golden rule was voted on at a Wine conf to solve the never ending regression issue. If AJ breaks it his maintainer ship would have to be reconsidered. So unless you can prove the patch is valid long term it will never be included. Also be aware that jack arts and esound and support were included before the golden rule come into effect. Today none of these would have made it in under current day control rules. Reason once we add crap to tree removing it can be imposable due to complaining users. Wine developers are not stupid. If we include Pulseaudio there will be no motivation form Pulseaudio people to work on a solution like gstreamer that could work well in time for wine. Also users will not use the ossp solution freely either if we include the Pulseaudio driver. Since what we will end up with is a stack of complaints that ossp wine works better than pulseaudio driver in wine so fix. Basically you are trying to force Pulseaudio on the developers of wine Oli Warner. You don't have to maintain the crap they do. So particular items will get refused. Did you not read. Pulseaudio is already part supported by the wine ALSA driver. Adding the Pulseaudio driver is also duplication since we would have to support Pulseaudio in 2 locations not 1. Yet you are not happy with that Oli Warner. The major difference here is what the Pulseaudio driver is based on. Some applications still work better with the OSS driver than the ALSA one. Since Pulseaudio driver is based of that you get some applications working that would not. Correct solution is get OSS working with Pulseaudio not hacking a OSS driver to talk to Pulse. Users still would have to switch between Pulse and ALSA driver to get application to work with Pulse. Problem here development would split between 2 drivers doing basically the same thing ie OSS driver and Pulse driver. Even then there are a lot of applications that don't like Pulseaudio lag. They are use to windows that don't place that of lag in way. OSS can be used on Apple. OSS and ALSA cover most platforms. Don't forget support gstreamer supports Pulseaudio and OpenAL outs so ends once and for all having to do support for other servers. Oli Warner you have to make your case. So far you are avoiding the flaws. Face the problem see what we see. Pulseaudio driver for wine does not pass the requirement rules.
Oli Warner wrote:> It's been about getting Wine audio working, even in imperfect conditions, right now.One of the main reasons Wine runs so many applications is a simple policy implemented number of years ago of not accepting hacks. ATM that PA patch is more of a hack then a correct working solution. Alexandre said this many times - he has no major issues with PA driver as long as it works _better_ then, and solves problems of what Wine already has. Adding just another driver that happen to work for some programs, is not acceptable. You might as well fix ALSA/OSS instead to work better with PA (if at all possible).