Announcement

Collapse
No announcement yet.

Fedora 11 Released

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

  • #11
    The Firefox issues I think are more of the program's own problems than of Linux; Linux Firefox is much slower than Windows Firefox.
    I never had any serious issue with PA. The times I did have problems, they were easily resolved by either editing /etc/pulse/daemon.conf or installing pavucontrol and related applets. Hell, on my laptop running KDE4 sound would always crash until dared to configure PA and use it as default.

    Comment


    • #12
      Originally posted by fart_flower View Post
      Unfortunately, I'm still having the same sound issues (snap, crackle, hiccup) that have been plaguing me since introduction of Pulseaudio. Yeah...
      Maybe your sound card driver is buggy, and doesn't work right with PA glitch-free, you can try to disable it by adding tsched=0 next to load-module module-hal-detect in your default.pa file. This would look like this:

      load-module module-hal-detect tsched=0

      And restart PA daemon. Take a look to this page http://www.pulseaudio.org/wiki/BrokenSoundDrivers


      You can also try to change the resample method in file daemon.conf. From highest to lowest quality and cpu usage:

      src-sinc-best-quality, src-sinc-medium-quality, src-sinc-fastest, speex-float-{10-0}, speex-fixed-{10-0}, ffmpeg, src-zero-order-hold, src-linear, trivial

      More details: http://ubuntuforums.org/showthread.php?t=789578

      Comment


      • #13
        Originally posted by Melcar View Post
        I never had any serious issue with PA. The times I did have problems, they were easily resolved by either editing /etc/pulse/daemon.conf
        Having to manually edit a configuration file isn't a serious issue? Try telling that to Mac or Win users -- they will laugh themselves silly.

        Comment


        • #14
          Originally posted by fart_flower View Post
          Having to manually edit a configuration file isn't a serious issue? Try telling that to Mac or Win users -- they will laugh themselves silly.
          Maybe that is because in windows you can't edit more than a couple of files?
          And Apple writes there OS for there Hardware, if something doesn't work, that would be stupid.

          Comment


          • #15
            Originally posted by fart_flower View Post
            Having to manually edit a configuration file isn't a serious issue? Try telling that to Mac or Win users -- they will laugh themselves silly.

            Sometimes you have to change certain settings under Windows so your sound card works as it should. I guess if the PA guys provided us with more fancy GUIs people wouldn't complain as much.

            Comment


            • #16
              Originally posted by KDesk View Post
              Maybe your sound card driver is buggy, and doesn't work right with PA glitch-free, you can try to disable it by adding tsched=0 next to load-module module-hal-detect in your default.pa file. This would look like this:

              load-module module-hal-detect tsched=0

              And restart PA daemon. Take a look to this page http://www.pulseaudio.org/wiki/BrokenSoundDrivers


              You can also try to change the resample method in file daemon.conf. From highest to lowest quality and cpu usage:

              src-sinc-best-quality, src-sinc-medium-quality, src-sinc-fastest, speex-float-{10-0}, speex-fixed-{10-0}, ffmpeg, src-zero-order-hold, src-linear, trivial

              More details: http://ubuntuforums.org/showthread.php?t=789578
              Sorry, but I've been through all that and am still bombarded with annoying digital farting noises.

              Comment


              • #17
                Originally posted by KDesk View Post
                And Apple writes there OS for there Hardware, if something doesn't work, that would be stupid.
                My brother-in-law's hackintosh has sound working just fine.

                Comment


                • #18
                  Originally posted by Apopas View Post
                  Try to rewrite it in a new disk. It happened me once something similar with openSUSE and was fixed in that way.
                  Thanks but DVD is good because i checked installation on VirtualBox.

                  Comment


                  • #19
                    Originally posted by Louise View Post
                    It is not "of course". If you look in the WINE bugzilla, you will find bugs, that only is present on 64bit systems.

                    Other programs have suffered, so I am interested in hearing from people that have tried the early 64 bit distributions, and how they compare with todays.
                    Having used 64-bit since 2003, it has some a long long long long way. Don't miss 32-bit at all. The two big holdouts were flash and java 64-bit plugins, but even those are in 64-bit flavor now.

                    If you at Fedora 10 x86 vs A64, the 32bit version DVD iso is 3.4GB and the A64 is 3.9GB.

                    I would expect the ratio would be somewhat the same for memory usage.
                    Can't judge by iso size at all. 64-bit releases typically have 32-bit compatibility libraries also on the iso which adds to it's size. As far as memory usage goes 1 - 1 1/2 gig seems just as zippy as it does on 32-bit (talking about desktop usage here).

                    64bit should only be faster, when you do float point calculations, on almost other cases, it should actually be a little slower, as you also have experienced.
                    Well when we are talking about prepackaged distro's this isn't always the case. There are many more variables to consider such as to maintain compatibility often packages are not compiled with the additional instruction sets that are only found on 64-bit procs. An distro that is compiled for i586 for example defaults to not even utilizing MMX. A 64 bit distro on the other hand is going to have all the instuction sets such as MMX and SSE at least enabled. Other applications that can greatly benefit are items such as dbases and of course apps that can use large amounts of addressable ram (pae works for some things in 32-bit but not all, one maya model I have gobbles up 5GB as it is).

                    Overall compatibility is great, I bet most of the wine issues you saw were actuall wine64 (running 64-bit window apps in wine) issues and not running wine32 in a 64-bit distro with the compatibility libraries installed. The benifits greatly out weigh the few items where it maybe extremely marginally slower (and I do mean extremely marginal). As a rule of thumb, performance wise a 64-bit os will run at least as fast as a 32-bit and in some cases can yield big gains for the little extra cost of memory.

                    Comment


                    • #20
                      Originally posted by Louise View Post
                      It is not "of course". If you look in the WINE bugzilla, you will find bugs, that only is present on 64bit systems.

                      Other programs have suffered, so I am interested in hearing from people that have tried the early 64 bit distributions, and how they compare with todays.



                      That most be your imagination. That is not my experience with 64bit RHEL5.3 for server use.

                      64bit might take up a little bit more memory, because some of the instructions now are longer.

                      If you at Fedora 10 x86 vs A64, the 32bit version DVD iso is 3.4GB and the A64 is 3.9GB.

                      I would expect the ratio would be somewhat the same for memory usage.



                      64bit should only be faster, when you do float point calculations, on almost other cases, it should actually be a little slower, as you also have experienced.
                      The higher memory usage is mainly because of 64 bit pointers.
                      They are needed for supporting/addressing more than 4GB of memory.

                      As for the speed, the x86_64 architecture has more registers than the traditional x86 architecture which can result in significant performance gains depending on the application.

                      Further SSE2 is part of the standard x86_64 ABI, this means every app can make use of SSE2 without having to do run time checking or being incompatible with some cpus.

                      x86_64 also removes the need for using HIGHMEM which is required on x86 for systems with > 1GB of ram. This adds an overhead that is not only measurable but in some workloads also very noticeable.

                      As for slowdowns x86_64 has a higher memory footprint (as I already said above), thus it can result into more cache misses which reduces performance.

                      But the advantages outweigh the disadvantages so if you have a x86_64 capable CPU and 1GB-2GB+ RAM you should use x86_64 (there is no reason not to do so).

                      x86_64 is fully backwards compatible so you can run 32bit apps just fine.

                      Comment

                      Working...
                      X