Announcement

Collapse
No announcement yet.

Wayland/Weston 0.95 Land In Ubuntu 12.10

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

  • #21
    Originally posted by AJSB View Post
    Bur even talking about PA, UBUNTU and others should give a TRUE AND SIMPLE WAY TO DISABLE IT
    I don't think so. They should just fix the bugs their users have with PulseAudio.

    Originally posted by AJSB View Post
    You say that is not UBUNTU fault that apps devs hardwire for PA....excuse me ?!? aren't those apps FOSS ?!? aren't many of those same apps also shipped with or for Slackware w/o PA ?!? So, what's so hard to UBUNTU make a kind of "if PA present use PA else use ALSA" in the code ?!?
    That's not how it works. Ubuntu and Debian compile packages with PulseAudio support enabled and Slackware doesn't. PulseAudio is compatible with ALSA so those applications will still work on Slackware altough they can't take use of any PA features and might not work properly. Application usually depend on libpulse that does exactly what you are after: if PulseAudio is not present then it uses ALSA.

    Comment


    • #22
      Originally posted by Ancurio View Post
      Please don't feed the trolls...
      *sigh* you're right...

      Comment


      • #23
        Originally posted by elanthis View Post
        First off, Wayland does no such thing, as Wayland is just a protocol. Weston very well might (don't know), but it's FOSS and you can change it if you want, or just use a different Wayland server implementation (I believe at least one other is already in development by the Qt folks, but I'm not sure).
        Gotcha.

        Originally posted by elanthis View Post
        "Professional gamers" (ugh) usually imagine the latency problem; they're interested in getting any possible edge, real or not, and are all too ready to blame anything and anyone except themselves when they don't play perfectly ("I don't suck, this computer just had vsync turned on, this is bullcrap!"). You get a lot of that in any competitive sport; people who believe in lucky socks, crap like that. There's feedback bias going into it. The monitor is physically incapable of displaying faster than its refresh rate, with or without vsync. That's not to say that it wouldn't better to have higher refresh rates than the relatively low 60hz that has become standard (120hz being the golden number, as it is slightly higher than what a human can perceive and has numerical properties that make it ideal for compatibility with legacy tech), but unless the monitor supports 120hz there is zero reason to actually render at 120hz. Note also that many games are just coded improperly and suffer additional lag in the whole system with vsync on; this is not the fault of vsync or the display system in general, but rather the game engines blocking everything until a vsync event instead of merely delaying rendering (triple buffering is the easy way to fix this for games that work that way, if your driver allows you to force it on).
        In the situation I referred to, all of the better players noticed the issue and it was clear there was an issue when they played. The next day when they had brought in the new monitors, the players no longer had an issue and it was clear they were playing better. I believe the issue was with SF3 3rd strike. The players would throw regular attacks out there and immediately after the attack, they'd do the movement of a super combo and should the attack connect and not be blocked, they'd hit the appropriate button and go directly into the super combo. With the slower monitors, the players weren't able to pull this off anymore. With the new monitors the next day, this was no longer an issue.

        I've no doubt that in the gamer's quest for lower latency, you see a lot of the same mindset that you see with audiophiles, but occasionally it is a legitimate issue. We had one better player from out of town come in and complain about lag issues on a cabinet with CRT. Either it was imagined (probably), or possibly his problem is that he was too used to the lag of a crappy LCD.

        Originally posted by elanthis View Post
        And this is why we try to get such high unlocked FPS in an engine and game despite the lack of a need to actually render that fast. If your game can only just barely handle 60 FPS on target hardware, then yes you have the problem where you drop to 30 fps. If you can render 200 frames then even if you hit a major problem and start running at 50% speed you're still well over the minimum 60 FPS. For general gaming, it's better to just lock the game to 30 fps for consistency if it can't handle 60, and for competitive play it's better to turn off all the graphical bells and whistles that you don't care about so the game always runs at 60 fps no problems.
        I agree.

        Originally posted by elanthis View Post
        That said, adaptive vsync is a thing (sync to 60 fps if it can handle it, and disable vsync if it can't), and it would be very easy to make a Wayland do that if it turns out to be a problem. I imagine that full-screen apps could be allowed to directly set the scanout buffer as well. As is, there is only a single extra context switch required when flipping buffers, but if Wayland has a command (or possibly it can be all automated by the server with no protocol changes at all!) to map a fullscreen window to that display's scanout buffer, the app/game would be in full control of when buffers are swapped.
        This is probably the best solution. I know at least some console titles implement this.
        Last edited by hiryu; 26 August 2012, 08:01 PM. Reason: Incomplete explanation.

        Comment


        • #24
          Posters suggesting that pro/competitive-gamers notice 10ms differences in latency are correct. When you're playing, you aren't really reacting, you're pushing buttons in a timed sequence. It becomes, "How quickly can I push F1 followed by F2, and still have them both register correctly in the sequence which you entered them". Press F2 too soon after F1, either the sequence isn't registered (comp thinks you pushed both at the exact same time), or one of the hits doesn't register at all.

          I hit the top 20 players on BC in Eve online as an interdictor pilot that leveraged a Low-latency setup that was little more than, F1 --> F2, F3, F2, click, F3, F2, click, F3, F2, click, F3, F4, click. The whole process took less than a second, and assured that whatever came through the stargate wasn't going anywhere. Watch it on video and it looks like I'm just spamming the keyboard and mouse for a moment. It couldn't be Fraps'd because Fraps would increase the latency too much to pull off the maneuver.

          F

          Still top 30 after 6 months away from the game.
          Last edited by russofris; 26 August 2012, 09:08 PM.

          Comment


          • #25
            Originally posted by Teho View Post
            I don't think so. They should just fix the bugs their users have with PulseAudio.

            That's not how it works. Ubuntu and Debian compile packages with PulseAudio support enabled and Slackware doesn't. PulseAudio is compatible with ALSA so those applications will still work on Slackware altough they can't take use of any PA features and might not work properly. Application usually depend on libpulse that does exactly what you are after: if PulseAudio is not present then it uses ALSA.
            Well i would agree with the bug fixes but the truth is that the PA dev seem unable to fix these bugs and actually have the nerve to dismiss them discarding the responsibility to the apps....witch is funny taking in account their goals for PA with a perfect integration with ALSA,etc.
            If their goals were a perfect integration , THEY FAILED to deliver.
            But maybe the real reason is another...i believe that there is something fundamentally flawed in PA that not could simply be solved with "bug fixes".....maybe KLANG would the right answer.

            ...and you didn't listen to me....so i will repeat:

            All apps that use audio in Slackware simply work and work properly w/o PA.

            Many apps (in special games, mind you, not only very demanding games but even simple JAVA FICS clients like JIN) that use audio via PA in *UBUNTU* or it's derivatives like *LINUX MINT* DON'T WORK AT ALL as for AUDIO goes.


            So you are seeing things upside down...ALSA, except for the users that need multichannel (...and NO serious player EVER uses multichannel in a game even if it supports it) works just fine w/o latency problems, mysterious sound mutes/crashes or w/o make game CTD.
            PA, OTOH, makes all those nasty things with a bunch of games.



            ...and talking about games....did you noticed how quiet VALVE been lately ?

            They promised updates and nothing yet.......

            Did Michael saw L4D2 at Valve running with audio ON or OFF ?!?

            I wonder if Valve was comparing only *video* performance w/o audio enabled in both Windows and LINUX and now hit a sudden audio "issue" .


            I bet that in the end we will see a SteamOS UBUNTU-based new distro w/o PA using only ALSA or maybe ALSA+KLANG....and Nouveau ditched with a proper NVIDIA blob preinstalled.
            Last edited by AJSB; 26 August 2012, 09:35 PM.

            Comment


            • #26
              Originally posted by AJSB View Post
              Bur even talking about PA, UBUNTU and others should give a TRUE AND SIMPLE WAY TO DISABLE IT if we want
              It is called pasuspend, but its seldom used as things work just fine by default. Also, you are full of lies: https://help.ubuntu.com/community/In...ion/MinimalCD/

              Short story? Don't like it, don't use it. Use your fav distro and let others use theirs. To each their own.

              My experience with PA is that it works just fine (Using Xubuntu 12.04). I run wine games (Ie. Skyrim, Civ4, etc) with sounds playing along with media players and web browsing (youtube et all) and it all works as expected, simultaneously even. I have reproduced the same experience in various different machines; you might have a particular problem with your setup.

              Valve doesn't need to do any disabling because the stuff works fine. What they might do is customize the interface for their own needs if they go with a linux console or games distro and need a much simpler interface; Ubuntu TV style.
              Last edited by Artemis3; 26 August 2012, 09:50 PM.

              Comment


              • #27
                Originally posted by Artemis3 View Post
                It is called pasuspend, but its seldom used as things work just fine by default. Also, you are full of lies: https://help.ubuntu.com/community/In...ion/MinimalCD/

                Short story? Don't like it, don't use it. Use your fav distro and let others use theirs. To each their own.

                My experience with PA is that it works just fine (Using Xubuntu 12.04). I run wine games (Ie. Skyrim, Civ4, etc) with sounds playing along with media players and web browsing (youtube et all) and it all works as expected, simultaneously even. I have reproduced the same experience in various different machines; you might have a particular problem with your setup.

                Valve doesn't need to do any disabling because the stuff works fine. What they might do is customize the interface for their own needs if they go with a linux console or games distro and need a much simpler interface; Ubuntu TV style.
                I know very well pasuspend, DOESN'T solve the problems AT ALL.
                Full of lies on what ?!? WTF as the minimal CD to do with PA and UBUNTU ?!? Does yjr minimal CD not include PA ?!? Let's imagine that it doesn't....SFW ?!? As soon as you start to pull the audio-related apps from the UBUNTU repositories, it will install PA.


                Yeah, in that you are correct, i don't like it , i don't use it.


                BS !!! You play the *WINDOWS* versions of them via WINE..
                Play a NATIVE game like ETQW in a PC with REALTEK AUDIO and press one of the VOIP buttons of the game....CTD.
                Install a JAVA game like JIN FICS Chess client, enable audio and let's see if you get any audio of it.
                etc, etc.

                Notice that i had two MB with build-in audio from different brands and same s**t with PA happened .

                Comment


                • #28
                  Originally posted by elanthis View Post
                  unless the monitor supports 120hz there is zero reason to actually render at 120hz. Note also that many games are just coded improperly and suffer additional lag in the whole system with vsync on; this is not the fault of vsync or the display system in general, but rather the game engines blocking everything until a vsync event instead of merely delaying rendering (triple buffering is the easy way to fix this for games that work that way, if your driver allows you to force it on)
                  Can you elaborate a bit on this? From what I know vsync should work the following way: once frame x is sent to the monitor rendering starts for frame x + 1 with whatever information is available at that time and not render anything else until the next vsync event. Now, at 60 fps the interval between frames is ~16ms. If rendering the next frame took just 4ms and somewhere between ms 4 and 12 new info comes from another player should a properly coded engine render a new frame that takes into account this new info?

                  Comment


                  • #29
                    Originally posted by AJSB View Post
                    Well i would agree with the bug fixes but the truth is that the PA dev seem unable to fix these bugs and actually have the nerve to dismiss them discarding the responsibility to the apps....witch is funny taking in account their goals for PA with a perfect integration with ALSA,etc.
                    If their goals were a perfect integration , THEY FAILED to deliver.
                    But maybe the real reason is another...i believe that there is something fundamentally flawed in PA that not could simply be solved with "bug fixes".....maybe KLANG would the right answer.

                    ...and you didn't listen to me....so i will repeat:

                    All apps that use audio in Slackware simply work and work properly w/o PA.

                    Many apps (in special games, mind you, not only very demanding games but even simple JAVA FICS clients like JIN) that use audio via PA in *UBUNTU* or it's derivatives like *LINUX MINT* DON'T WORK AT ALL as for AUDIO goes.


                    So you are seeing things upside down...ALSA, except for the users that need multichannel (...and NO serious player EVER uses multichannel in a game even if it supports it) works just fine w/o latency problems, mysterious sound mutes/crashes or w/o make game CTD.
                    PA, OTOH, makes all those nasty things with a bunch of games.



                    ...and talking about games....did you noticed how quiet VALVE been lately ?

                    They promised updates and nothing yet.......

                    Did Michael saw L4D2 at Valve running with audio ON or OFF ?!?

                    I wonder if Valve was comparing only *video* performance w/o audio enabled in both Windows and LINUX and now hit a sudden audio "issue" .


                    I bet that in the end we will see a SteamOS UBUNTU-based new distro w/o PA using only ALSA or maybe ALSA+KLANG....and Nouveau ditched with a proper NVIDIA blob preinstalled.

                    You're implying that Steam, or for that matter, any serious game devs actually talk to PA. They don't. They use abstractions like OpenAL or SDL_mixer, which work flawlessly with PA.

                    You're talking about "bugs in PA". Can you point out some, as well as the source code in PA that is responsible for them? That would certainly interest me.
                    Maybe I'm just biased because I've been running PA since Fedora14 without any problems whatsoever.

                    Oh, and you might want to consider that devs of normal apps might phase out direct ALSA support entirely because PA has become the de facto standard.
                    And your argument would become the same as
                    "Why do they shove GTK2 down our throats? Everything worked perfectly with GTK1, but now everything breaks when I remove GTK2!".
                    Distros can't accommodate for every nitpick users might have. "I don't wanna use Devkit! Why won't they let me use HAL?" "I don't wanna use DBus! Why won't they let me use CORBA?"
                    This is free software. If something doesn't work for you, move on.

                    Comment


                    • #30
                      Originally posted by Ancurio View Post
                      Distros can't accommodate for every nitpick users might have. "I don't wanna use Devkit! Why won't they let me use HAL?" "I don't wanna use DBus! Why won't they let me use CORBA?"
                      This is free software. If something doesn't work for you, move on.
                      That's pretty much what Gentoo is trying to do, and it's doing a pretty decent job. I have 3 machines running Gentoo, 2 of them running over plain alsa and one with PA, all 3 work flawlessly. And I could even switch one to OSS if I wanted, though I think there would be some apps that no longer have OSS output even as compile time option...

                      Comment

                      Working...
                      X