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

Re: PulseAudio as a sound output?

by Dave Phillips

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

Oct. 8, 2007

Re: PulseAudio as a sound output?

by Maarten Lankhorst

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.

Oct. 8, 2007

Re: Moving the wine status pages to the wiki

by Chris Howe

I think that's a great idea but would it be cheeky of me to suggest that at the same time, the general state of the to-do information be updated as well? Just as a somewhat newbie diving in, there's a lot of stuff spread out over various places in both www.winehq.org / wiki.winehq.org that describes current status, todo lists for dll's in a couple of formats, suggested things that need to be fixed, some of the lists have ticks against them - (does this mean they need to be fixed still?) Then there's the checklists on the various developer pages... It's hard to look at the website and definitively think "right, what needs doing?" when there's such a spread of information, some of which doesn't look like it's being maintained. -- Chris 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? > > Cheers, > Kai > > > ------------------------------------------------------------------------ > >

Oct. 8, 2007

Re: WineConf - Slides online

by Kai Blin

On Sunday 07 October 2007 13:41:10 Marcus Meissner wrote: > Feel free to upload more slides, and if you are lazy, send them to > me and I will ;) Done. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Oct. 8, 2007

Re: Bugzilla and spam harvesting

by Kai Blin

On Sunday 07 October 2007 23:07:02 Dan Kegel wrote: > Should we modify our Bugzilla to hide email addresses at least a little? > I'd like that myself, and users request it occasionally. > Just now, somebody asked that he be removed from > bugzilla because it doesn't do this. > - Dan Bugzilla does some simple obfuscation of the email addresses. I don't know how useful that obfuscation is. The @ sign is replaced by @ in the html source. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Oct. 8, 2007

Moving the wine status pages to the wiki

by Kai Blin

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? Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Oct. 8, 2007

Re: Request to be unbanned from #winehq (Jan Zerebecki)

by Christoph Frick

On Mon, Oct 08, 2007 at 08:09:37AM +0200, luis.busquets(a)ilidium.com wrote: > Which program do I have to use to get connected in the #winehq > channel? > > I have truly been out of chatting for a long time. http://www.winehq.org/site/irc -- cu

Oct. 8, 2007

Re: Request to be unbanned from #winehq (Jan Zerebecki)

by luis.busquets＠ilidium.com

Dear all, Which program do I have to use to get connected in the #winehq channel? I have truly been out of chatting for a long time.

Oct. 8, 2007

Re: PulseAudio as a sound output?

by Damjan Jovanovic

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

Oct. 8, 2007

Re: 1.0 Bugs - Microsoft Office 2003

by James Hawkins

On 10/8/07, Roland Kaeser <roli8200(a)yahoo.de> wrote: > > Hello > > Sorry for my cheek, but don't a 1.0-Version mean that every Windows app > works on Wine? > There will never be a point where all Windows apps work in Wine. As it stands, we have a bigger compatibility goal than current versions of Windows, as we support apps all the way back to Win 3.1. Unfortunately, it's just not possible to support all known apps. -- James Hawkins

Oct. 8, 2007