Wine Pumps Out 1.3.31 Release
Phoronix: Wine Pumps Out 1.3.31 Release
Wine 1.3.31 was released today...
Has anyone seen an update on the intrusion of wine when 1.3.30 was affected?
Not sure what you mean there... The user information for the AppDB and bugtracker were compromised, not the code AFAIK, if that's what you are referring to.
Originally Posted by sabriah
Anyway, I've really been wondering about what they meant with "sound fixes" since they reworked the audio. For each release it's getting more of a PitA for me to get anything out of the speakers.
When PulseAudio finally works decently and major distros make it their default sound system, I find it extremely disingenuous to break compatibility with it.
A few releases back, I found out I had to change Hardware Acceleration from "Emulation" to "Full"... Fair enough, at least it worked.
Then another update, completely new sound control panel in wincfg, much fewer configuration options (yeah... great move there...) and after fiddling I got sound back changing the windows version to vista.
And now more "audio fixes" and I'm back to square one, only with fewer options to play around with trying to figure out how the &%#¤ I'm supposed to get sound working.
mmdevapi tweaking yields nothing.
Seriously what's the point?
Last edited by PsynoKhi0; 10-22-2011 at 07:43 AM.
Is there a planned 1.3.37 release?
Just kinda curious if they are gonna do that version or not.
If the code is ok I'm ok. I just didn't know.
Originally Posted by PsynoKhi0
Audio redesign is one of the main task to do before next major release 1.4. If you use development version of wine, except some quirks.
Originally Posted by PsynoKhi0
One interesting thing that wasn't mentioned in the release notes is that there were DirectInput fixes, so you no longer need to use winetricks for several applications, like Mass Effect.
Yeah I threw a tantrum out of frustration though the nagging feeling that things are only getting worse is getting tedious.
Originally Posted by tuke81
mmdevapi support = good.
Originally Posted by PsynoKhi0
windows audio session (wasapi) support = good.
length of audio pathway chain (= number of data copies, = added latency) in new audio architecture = bad, bad, bad, bad.
Normally, support for new Windows APIs in Wine is an uncontroversial win. But with audio there's really a dilemma. By using mmdevapi as the core interface between the host platform and the Win32 APIs, and using OpenAL as the core interface on the host-side, we're really putting a lot of layers in between the application and the speakers. Let's have a look:
The best-case path for a DirectSound app, with robust userspace software mixing on a card that does not support hardware mixing (>99% of all cards):
Wine app calling DirectSound API -> mmdevapi -> OpenAL "frontend" API -> OpenAL backend (e.g. pulseaudio) -> pulseaudio-libs -> pulseaudio daemon -> ALSA-lib -> alsa-hw (kernel) -> speakers.
If we wanted to minimize layering and implement a minimum "direct path" with as few copies as possible, while maintaining pulseaudio, we could do something like this instead:
Wine app calling DirectSound API -> pulseaudio-libs -> pulseaudio daemon -> ALSA-lib -> alsa-hw (kernel) -> speakers.
Of course this wouldn't work for Crossover Mac, so the codeweavers guys would never ever merge such a direct path, since they'd have to separately maintain an OS X core audio support. That reason alone is essentially the reason why we have to have another level of indirection (OpenAL) on the host-side. If Crossover Mac as a product didn't exist, then more than likely a direct path to PulseAudio would work for all the other *NIX systems out there. Or the ones that matter.
On the Win32 side, I kind of agree with layering all the Windows audio APIs (DSound, winmm, KS?, wasapi) on top of mmdevapi, because this means you only need one well-defined, stable interface between the win32 side and the native environment. Then your architecture looks like an hourglass. On the top is the "wide" part of the hourglass that represents an explosion of emulation-side APIs that are supported in the emulated application. The "stem" of the hourglass is the One-True-Audio-Path tight coupling between mmdevapi on the emulation side, and OpenAL on the native (host platform) side. And on the bottom of the hourglass is of course the explosion of native backends that any given OpenAL implementation might support, from OS X Core Audio to Pulseaudio, to ALSA, to OSS (and still others -- even DirectSound if you're running wine on windows, lol). This gives kind of a Gallium3d type architecture but for audio, where you have "many inputs" on one side, a centralized platform that communicates from the inputs to the outputs, and "many outputs" on the other side (i.e., the G3D hardware drivers which sit behind the G3D API, which is called by many state trackers). It's a fairly modern architectural approach that is popular in middleware software.
Bottom line is, given our limited development resources, "hourglass" architectures are probably the most efficient (in terms of man hours to implement) for complicated open source projects.... so in that respect, I'm in favor of the new Wine architecture, as well as Gallium3d, for mapping many frontend APIs to many backend devices. It's a clean design that requires less code, as long as the middleware platform in the center is rock-solid.
But I don't think that these new platforms allow -- by design -- the type of direct latency control that is desired for many high-performance audio/visual apps. There's just too many layers to translate between. You end up doing several copies, with context switches all over, and you end up setting up and tearing down a lot of state at each layer. Implementing each layer to do something more sophisticated, like save power and voluntarily shut itself off when not in use, is even trickier. The more layers you add, the harder it is to tune the pipeline to be power-efficient, high-throughput, and/or low-latency. In fact, you can't even tune for any of these goals, unless each layer of the platform is as flexible as every other. But that is highly unlikely, given that the set of APIs that are being translated between range in age from the mid to late 80s (winmm) to 2006 (wasapi, pulseaudio).