Announcement

Collapse
No announcement yet.

Wine Developers Fight Over PulseAudio Driver

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by Teho View Post
    I don't think so. PulseAudio is still the de facto audio server so supporting it as well as possible should be the top priority.
    I think this is one of the core issues. When you introduce something new rather than fix what already exists, you create a lot of pain. For years PA was wreaking havoc on user's systems. That was really a very bad situation. This shouldn't have happened.

    PulseAudio takes radically different approach to the problem than ALSA so just rewriting stuff isn't possible. I still don't understand why you think that ALSA API is the end of all Linux audio APIs. I mean seriously even if ALSA was extended so far that it would resemble the PulseAudio we have now its APIs would have probably changed completely anyway.
    I believe that the correct approach would be to implement all the stuff in the ALSA library, simply because it avoids having two distinct APIs, controlled by different people. If the core functionality is in ALSA, all you need are simple GUI tools for configuring that functionality.

    But the base argument is really simple: if a problem turns up in PA, should we replace it again instead of enhancing it? I say no. You seem to say yes.

    Comment


    • #32
      Originally posted by russofris View Post
      Are you certain? Then why does PA exist? I was under the impression that this was the major obstacle that PA was created to overcome. I distinctly recall having to mess around with my .asoundrc and creating multiple virtual cards in order to get two applications to playback simultaneously under Alsa, and to assign a volume to each individual application. This was some time ago though (2006-ish).
      There's one "hw" device for exclusive access, and there's a dmix device that I guess you can call virtual. The hw device can only be opened by one application at a time. The dmix device can be opened simultaneously.

      Per-application volume is not supported well. There's no automation for it, you need to set up everything manually and assign mixer controls to specific applications, which is totally useless. It's one of the things PA chose to replace instead of fix. Well, it was to be expected I guess. Linux devs usually want their own projects instead of joining an existing one. Fame and honor and all that :-/

      Comment


      • #33
        Originally posted by RealNC View Post
        But the base argument is really simple: if a problem turns up in PA, should we replace it again instead of enhancing it? I say no. You seem to say yes.
        It's not that simple. We got the architecture right with PulseAudio so there is no need to start from scratch. The situation was quite different with ALSA. The ALSA APIs that PulseAudio is using are for controlling the hardware and are not something that other application developers would like to touch anyway. All the userspace developement has happened in PulseAudio and Jack for years now. Even if something could have been done differently six to eight years ago it's now distant past and quite frankly doesn't matter at all.

        Comment


        • #34
          to anyone that doesn't really understand the alsa pulseaudio debacle, first put this in your mind, its not pulse vs alsa, its pulseaudio(or pulse for short) vs dmix. anyone who doesn't make this distinction is not quallified to discuss it.
          ok. so, alsa is, like mesa, a name we give to a project that includes several related componants of the audio stack. theres the hardware drivers (this is what alsa normaly is reffering to), there is libalsa (an api used to actualy send the audio data to the hardware) and then there is dmix. pulse only repalces dmix, and it kinda replaces libalsa in a sense but not really. see, it use to be when you wanted your program to output sound, you would use the libalsa library directly. libalsa represents the hardware pretty much exactly how the hardware is designed. this is bad, because when you swite a program, you just want the sound to sent to the hardware, you dont care about how the hardware works. you might care about higher level concepts like ho many channels does the audio stream have or whats the bitrate, but you dont care about how the hardware works, or what limitations it may have orwhatnot. so the alsa devs kinda made some of the libalsa api kinda generic so that software devs could actualy write software to it. this ment that a simple 2 channel output was pretty standardized but any fancy stuff was often problomatic. also, no mixing if the hardware didnt support it. most hardware doesn't so obviously it sucked at that time. so they were quick to come up with dmix. dmix basicaly emulated a simple mixing sound card. in the alsa configuration file you would have your default audio output, whitch normaly redirected you to your main audio card, now it would output to the fake dmix device, then the dmix device would output to your main sound card. it worked, but it had its flaws. one, programs that made extensive use of the low level libalsa library functions, like wine, could easily hog the output and negate dmix alltogether. aldo dmix didnt use quick algorithms and ras pretty limited to basic functionalty coverage. also still you had end user applications and their high level auio api's (openal, sdl, gstreamer) using libalsa directly. it is for these reasons that dmix is a very good example of a hack, it worked but it had no long term value.

          what pulseaudio did was come in, and replace dmix, and replace libalsa as a high level api (kinda they have a pulsealsa plugin to provide a cut down libalsa that satisfies most programs that only output through libalsa). now a program will use a high level api such as gstreamer, that will use libpulse to talk to pulseaudio, who will mix the stream with any other current output streams and pass it allong to the next link in the chain whether it be throguh the entowkr to another computer or right on through to the hardware. pulseaudio will talk to the hardware through libalsa, that means that pulseaudio will take care of preping the output stream to match the hardware. since pulseaudio is a project that compleatly focuses on the middle layer, it pretty much spent a lot of time on making a super efficient mixer. it has various options of how well or how fast you want the mixer to operate, it was designed as a zero copy mixer, meaning it doesnt copy the streams around, only one instance of the stream data is ever stored in memory, and it is also designed around liboil, a library that allows pulseaudio to mkae use of the risc additions of your proccessor (like mmx, or sse) to speed up parts of the mixing.

          saying something like programs should talk to libalsa directly like they did before is really akin to saying programs should talk to libdrm directly(thus bypassing opengl, mesa, gallium3d, X)

          Comment


          • #35
            Hm, I hope they clear this misconception up about the second driver. I as a user in the end just want to stop having to do "pulseaudio -k" every half hour while playing a game in Wine and restarting it as well, because the audio chokes up and dies on a lot of simultaneous sounds being played.

            Comment


            • #36
              Originally posted by Teho View Post
              It's not that simple. We got the architecture right with PulseAudio so there is no need to start from scratch. The situation was quite different with ALSA. The ALSA APIs that PulseAudio is using are for controlling the hardware and are not something that other application developers would like to touch anyway. All the userspace developement has happened in PulseAudio and Jack for years now. Even if something could have been done differently six to eight years ago it's now distant past and quite frankly doesn't matter at all.
              Reading the problems Wine has with PA in the link given in the original post of this thread, it seems doubtful that PA has indeed got the architecture right though.

              Comment


              • #37
                Jesus, the audio people are worse than the graphics peeps! Can't we get these 2 basic features (audio & video) under control? Is it really so difficult that people can't decide on a uniform way of producing sound of Linux without resorting to "MINE IS BETTER THAN YOURS!1!!!1!" mentality? Ridiculous.

                For Linux to move forward, there's got to be a consensus on this very basic functionality. Fork if you need to, but not because of meaningless differences. Fork because the underlying tech is truly different, innovative or disruptive. Right now we've got a hoard of shit doing basically the same thing. This it truly very sad.

                Comment


                • #38
                  Originally posted by RealNC View Post
                  Yes, though many users remove it. And since now you can create a setup where ALSA applications can be redirected seamlessly to PulseAudio, it makes more sense to support ALSA only. The PA API makes less sense now.

                  It does solve a whole lot of problems. But it does that using the wrong approach. The userspace part of ALSA should be doing that. Everything should be nicely integrated using a single API instead of two.
                  You're forgetting two points here. First of all, ALSA applications can't be seamlessly redirected to PulseAudio - after all, if that was the case, then we wouldn't need the PulseAudio driver for Wine in the first place. And from personal experience, if I use either ALSA directly or ALSA to PulseAudio to ALSA to record my microphone, the recording has so much popping sound that SoX refuses to process it; using PulseAudio directly produces crystal clear sound. So no, the process is not seamless at all, as the buggy nature of ALSA seems to do something wrong with the audio before PulseAudio takes over.

                  The second point is about APIs. Benjamin there gave a fairly good example. Furthermore, you must not forget that PulseAudio is in fact not strictly related to ALSA. It also accepts sound sent to all of the other sound systems - OSS, ESounD, Jack, etc. and as such acts like a very universal compatibility layer. And I think PulseAudio isn't even strictly limited to ALSA output, either, it's higher level than that. So its code is long-term, as even if someone was to create another implementation that is better than ALSA to replace it, PulseAudio code could be reused to work with that, too. So it's not a competing API, it's a central API.

                  The defaults chosen for PulseAudio may not be ideal, yes, but I think it's set to work fairly efficiently. It uses the new timer-based scheduling that has advantages over the interrupt-based one (I think it has something to do with power saving, but I'm not certain), but depending on your hardware it may not work correctly. And I assume that there is no real way, aside from user input, to determine whether it's working correctly or not with your hardware. Same with the resampling methods - sure, they could set the trivial method to be the default, and it would work on all hardware. However, that also means that you'd be getting the worst possible sound, even if most of the sound cards/chips can handle better resampling methods. So from what I can gather, PA uses efficient, while not perfectly safe defaults, and it's up to you to tweak them according to your hardware.

                  Comment


                  • #39
                    The horde of sh*t comment had me laughing but it's true. Linux is an eighteen wheel tractor-trailer at this point with all the reinventing the wheel it does.

                    To the guy with the heavy load... The only time my sound ever dies is when I am writing DVD structures to disk and it's momentary at best so I don't know what you're doing but it's probably more intensive that whatever you do on your Windows OS either that or the player you're using buffers further on the Windows OS (since I am assuming disk i/o). As far as a CPU choking on audio you would have to be running a 10 year old single core.... or pulse audio.

                    Seriously though, I always had sync issues with pulse.Now I just use alsa and haven't had any issues.

                    Comment


                    • #40
                      Wine Project Crew are crazy if they don't go with PulseAudio. Obviously allow ALSA too, but PA should be the default.

                      Comment

                      Working...
                      X