Results 1 to 10 of 10

Thread: Wine Pumps Out 1.3.31 Release

  1. #1
    Join Date
    Jan 2007
    Posts
    15,097

    Default Wine Pumps Out 1.3.31 Release

    Phoronix: Wine Pumps Out 1.3.31 Release

    Wine 1.3.31 was released today...

    http://www.phoronix.com/vr.php?view=MTAwNDI

  2. #2
    Join Date
    Aug 2007
    Location
    Europe
    Posts
    401

    Default

    Has anyone seen an update on the intrusion of wine when 1.3.30 was affected?

  3. #3
    Join Date
    Feb 2010
    Posts
    519

    Default

    Quote Originally Posted by sabriah View Post
    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.

    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 08:43 AM.

  4. #4
    Join Date
    Sep 2010
    Posts
    2

    Default Is there a planned 1.3.37 release?

    Just kinda curious if they are gonna do that version or not.

  5. #5
    Join Date
    Aug 2007
    Location
    Europe
    Posts
    401

    Default

    Quote Originally Posted by PsynoKhi0 View Post
    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.

    [...]

    Seriously what's the point?
    If the code is ok I'm ok. I just didn't know.

    Thanks.

  6. #6
    Join Date
    Apr 2007
    Location
    Arctic circle, Finland
    Posts
    297

    Default

    Quote Originally Posted by PsynoKhi0 View Post
    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?
    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.

  7. #7
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,599

    Default

    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.

  8. #8
    Join Date
    Feb 2010
    Posts
    519

    Default

    Quote Originally Posted by tuke81 View Post
    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.
    Yeah I threw a tantrum out of frustration though the nagging feeling that things are only getting worse is getting tedious.

  9. #9
    Join Date
    Sep 2008
    Posts
    989

    Default

    Quote Originally Posted by PsynoKhi0 View Post
    Yeah I threw a tantrum out of frustration though the nagging feeling that things are only getting worse is getting tedious.
    mmdevapi support = good.

    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).

  10. #10
    Join Date
    Apr 2007
    Location
    Arctic circle, Finland
    Posts
    297

    Default

    Hmm I must admit that I've never used pulseaudio. Fed up alsa and linux audio problems years ago and changed to OSSv4 and haven't had any problems with wine audio since then. Now a days most problematic audio problems that I have are some native linux programs that are hardcoded to alsa

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •