Announcement

Collapse
No announcement yet.

Systemd 199 Has Its Own D-Bus Client Library

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

  • #61
    Originally posted by frign View Post
    And? I never stated to evaluate it; I pointed out configuration and code was separated.
    And that's also how it works in systemd.

    Originally posted by Ericg View Post
    I just pulled up htop and checked pulse's CPU usage while playing music-- sorted by CPU%, pulse was at the bottom of the list alongside packagekit (idle) and samba (no connections sending or receiving). If pulse is spiking your CPU or someone elses CPU its from buggy drivers or bad configurations (very possible. Check the arch wiki, pulse's defaults dont work on all cards. Sometimes they need adjusting)
    Huh, I never really tried this, but you're right. I get 1% CPU usage by Amarok, and PulseAudio itself is constantly at 0%. Pretty cool, I didn't quite expect that. And that's while running with ctxfi drivers, which are far from optimal, while using default settings...

    Comment


    • #62
      Originally posted by Teho View Post
      The OpenRC people seem to think that Wikipedia is their marketing platform. It doesn't have sources either and there's even a "This article's tone or style may not reflect the encyclopedic tone used on Wikipedia. See Wikipedia's guide to writing better articles for suggestions. (December 2012)" banner on top of the page. All in all that part of the article should probably be removed as off-topic, unreferenced and biased trash.

      Could you point me where the kernel part of Jack is? ...and how exactly does it make Jack better than PulseAudio.

      Neither of the articles I linked were authored by Lennart.
      Ok, agreed. I forgot to note that, because I am also a Wikipedia-sceptic and will investigate myself now in regards to SLsOC. In which way OpenRC use it as a marketing-platform is questionable.

      Jack is in Kernel, because there are extensions to the ALSA-implementation for Jack support (especially in regards to timers, esp. HRTs)

      Ok, my mistake in regards to the articles. I misread one earlier post and I thought it was actually part of Lennart's blog, not actually checking it.

      Comment


      • #63
        Originally posted by GreatEmerald View Post
        And that's also how it works in systemd.



        Huh, I never really tried this, but you're right. I get 1% CPU usage by Amarok, and PulseAudio itself is constantly at 0%. Pretty cool, I didn't quite expect that. And that's while running with ctxfi drivers, which are far from optimal, while using default settings...
        If a sound daemon was using more than 1% in regards to today's advanced hardware, I would be definitely concerned. How about RAM?

        Comment


        • #64
          Originally posted by frign View Post
          If a sound daemon was using more than 1% in regards to today's advanced hardware, I would be definitely concerned. How about RAM?
          0.0%

          VIRT: 539M
          RES: 1844
          SHR: 1522

          (As reported by htop)

          Comment


          • #65
            Originally posted by frign View Post
            In which way OpenRC use it as a marketing-platform is questionable.
            Well it used to have a comparison table like this... on top of the SLOC comparisons.

            Originally posted by frign View Post
            Jack is in Kernel, because there are extensions to the ALSA-implementation for Jack support (especially in regards to timers, esp. HRTs)
            Doesn't PulseAudio use exactly the same timers stuff as Jack? At least PulseAudio is build around timers and some if not most of the early problems relating to PulseAudio existed because the ALSA drivers reported wrong timing information.

            Comment


            • #66
              About the sound thing, why don't turn back oss?

              Comment


              • #67
                Originally posted by Thaodan View Post
                About the sound thing, why don't turn back oss?
                Lack of development, buggy drivers, very limited features (I know for a fact no jack detection), and in-kernel nature meant that its buggy drivers could bring down the whole kernel.

                EDIT: From the Arch wiki (https://wiki.archlinux.org/index.php/Open_Sound_System)

                Comparisons with ALSA

                Some advantages and disadvantages compared to using the Advanced Linux Sound Architecture.
                OSS Advantages (users)
                Per-application volume control.
                Lower latency due to everything running within the Linux Kernel. Initial response time in audio applications is usually better.
                OSS always has sound mixing, ALSA does not.
                Sound mixing is of higher quality, due to OSS using more precise math in its sound mixing.
                Some legacy cards have better support.

                OSS Advantages (developers)
                Support for drivers in userspace.
                Cross-platform (OSS runs on BSDs and Solaris).
                Cleaner and easier to use API.

                ALSA advantages over OSS
                Better support for USB audio devices.
                Support for Bluetooth audio devices.
                Support for AC'97 and HD Audio dial-up soft-modems such as Si3055.
                Better support for MIDI devices.
                Support for suspend.
                Better support for jack detection.
                Note:
                OSS has experimental output support for USB audio devices, but no input.
                Last I checked, OSS actually has NO support for suspend. If you want to suspend you have to unload OSS, suspend, then reload it on wake.
                Last edited by Ericg; 03-27-2013, 07:12 PM.

                Comment


                • #68
                  Originally posted by Thaodan View Post
                  About the sound thing, why don't turn back oss?
                  Why would anyone want that? It's severly outdated architecture, solves no problems and adds quite a few and Linux already has a excellent audio infrastucture that supports incredible ammount of hardware (over 4000 chips or something). I doubt anyone is interested in reimplementing that. ALSA is also very widely used (Android, Chrome OS, desktop Linux...).

                  There was an interesting debate between dawhead (Paul Davis, the lead developer of Ardour and Jack) and Hannu Savolainen (the lead developer of OSSv4) here in the comments if you are interested in reading.
                  Last edited by Teho; 03-27-2013, 07:13 PM.

                  Comment


                  • #69
                    Originally posted by Ericg View Post
                    0.0%

                    VIRT: 539M
                    RES: 1844
                    SHR: 1522

                    (As reported by htop)
                    Nice values, even though, ofc, this depends on how much it is idling.
                    Memory could be better, though.

                    Comment


                    • #70
                      Originally posted by duby229 View Post
                      The only thing that PA does that is kinda nice is its per application volume control. Thats it. But its soooo huge that it simply isnt worth it to get that slight advantage. It's performance is so bad that even the slightest cpu load makes it skip and crackle. Simply put, it's some of the worst software ever written for little to no gain with lots and lots to lose.

                      Alsa running by itself on the other hand will easily fit the needs of almost everyone.

                      Yeah, well, you know, that's just, like, your opinion, man.
                      Right now I'm listening to some music while running two instances of dd as root which is pegging the cores. Music plays back perfectly. BTW, I running this on T7500 cores, not that that should matter.

                      Comment

                      Working...
                      X