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


                      • #71
                        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)
                        No, Jack is NOT in the kernel. Sure it uses timers, so what? ~ that still does NOT make it apart of the kernel by any stretch of the imagination. It is no more apart of the linux kernel, than it is of XNU kernel (MacOSX) or NTOSkernel (Windows).

                        Jack is a user-space daemon, on all platforms. end of story.

                        Comment


                        • #72
                          Originally posted by varikonniemi View Post
                          While many have bad things to say about Poettering, there is no denying the fact he is one of the most notable opensource developers currently. Not THE most notable, just one very prominent figure.

                          I think the work he does is valuable; systemd was severely needed, and he delivered very well.
                          Back that up please. And not with circular rhetoric. That is you can say it's "severely needed" because you SAY it's "severly needed'. I don't think that even Lennart would make such a statement. Lennart writes code. But his logic and reasoning are often based on his own motives and desires. Lennart isn't interested in making things necessarily "better"... he's much more interested in just... well... making things.... That's not necessarily a bad thing, but I think if you can understand that, you won't necessarily want to crucify Lennart when your distro craps out (and it will, I promise) when you use his stuff (pre fixing by the overall community as a whole).

                          Just because I person can spew forth a LOT of code and create massive scope creeping projects doesn't mean he's "most notable"... unless you mean notable going both ways (positive and negative). The guy can throw code like nobody's business.. that doesn't mean it's always a good thing.

                          Since we're making baseless claims... here's mine. I wager that 90% of the problems that distributions will face over the next 2-3 years (things that affect the end user and their ability to have a functioning system without a ton of workaround and glueware) will be attributable directly and/or indirectly to systemd. In fact, I'll go over the top and say that the reputation of Linux will be damaged greatly over the next 2-3 years due to systemd and modifications made to support it's implementation. And that damage won't make people run to Ubuntu, etc.. it will make them run to either closed source systems with Linux at the core (which btw, is one of the end goals that systemd creates btw), or they run away from Linux entirely... and in all fairness that's unfair... but that's what I see happening (and it's already beginning).

                          I'm not saying that an overhaul of init wasn't a good idea... but I think you can figure out what I am saying... In the next 2-3 years either Lennart will become the savior of the world (which I think is VERY unlikely) or we'll all curse the day that systemd (note: the pains of poorly designed software can be fixed and will be fixed over time) was created. It will be interesting...

                          I'm sort of waiting for Linus to speak up... and he will when his Linux distro of choice stops working well....

                          Comment


                          • #73
                            Originally posted by GreatEmerald View Post
                            ...PulseAudio itself is constantly at 0%...
                            For a long time I'm wondering what's wrong with my setup. Google didn't help.

                            This is with a emu10k1 card (SB Live! 5.1 Dell OEM [SB0228]).

                            I'm happy for any help with this.

                            Comment


                            • #74
                              Great read!

                              Originally posted by cjcox View Post
                              Back that up please. And not with circular rhetoric. That is you can say it's "severely needed" because you SAY it's "severly needed'. I don't think that even Lennart would make such a statement. Lennart writes code. But his logic and reasoning are often based on his own motives and desires. Lennart isn't interested in making things necessarily "better"... he's much more interested in just... well... making things.... That's not necessarily a bad thing, but I think if you can understand that, you won't necessarily want to crucify Lennart when your distro craps out (and it will, I promise) when you use his stuff (pre fixing by the overall community as a whole).

                              Just because I person can spew forth a LOT of code and create massive scope creeping projects doesn't mean he's "most notable"... unless you mean notable going both ways (positive and negative). The guy can throw code like nobody's business.. that doesn't mean it's always a good thing.

                              Since we're making baseless claims... here's mine. I wager that 90% of the problems that distributions will face over the next 2-3 years (things that affect the end user and their ability to have a functioning system without a ton of workaround and glueware) will be attributable directly and/or indirectly to systemd. In fact, I'll go over the top and say that the reputation of Linux will be damaged greatly over the next 2-3 years due to systemd and modifications made to support it's implementation. And that damage won't make people run to Ubuntu, etc.. it will make them run to either closed source systems with Linux at the core (which btw, is one of the end goals that systemd creates btw), or they run away from Linux entirely... and in all fairness that's unfair... but that's what I see happening (and it's already beginning).

                              I'm not saying that an overhaul of init wasn't a good idea... but I think you can figure out what I am saying... In the next 2-3 years either Lennart will become the savior of the world (which I think is VERY unlikely) or we'll all curse the day that systemd (note: the pains of poorly designed software can be fixed and will be fixed over time) was created. It will be interesting...

                              I'm sort of waiting for Linus to speak up... and he will when his Linux distro of choice stops working well....
                              I couldn't have put it better!
                              The day will come where will realise how important sucklessness and smartness is in software. When Lennart Poettering is so good at puking code, he should start working on the Kernel and stop trying to reinvent the wheel with bloated user-space-"solutions" attempting to fix problems which could be solved more efficiently or aren't even existent, but I guess this would blow his scope, because you actually have to take care of making your code work once you enter Kernel-space.
                              Same with systemd: It generally is a collection of tools already existent and very efficient with OpenRC and others. When systemd-zombies attempt to push you to the wall stating the feature-richness of systemd, then they do it in attempt of F.U.D. without knowing these features have been existent in the current
                              solutions _for years_!

                              I am glad to read I am not the only one opposing this guy and his agenda so harshly.

                              Comment


                              • #75
                                Originally posted by ninez View Post
                                No, Jack is NOT in the kernel. Sure it uses timers, so what? ~ that still does NOT make it apart of the kernel by any stretch of the imagination. It is no more apart of the linux kernel, than it is of XNU kernel (MacOSX) or NTOSkernel (Windows).

                                Jack is a user-space daemon, on all platforms. end of story.
                                There is more to Jack than the Daemon (jackd), smartass. It is part of the Kernel, because there is active support for its user-space-implementation. It is as if you were stating udev wasn't part of the Kernel only because it is just the user-space tool to manage the /dev-FS (which is explicitly right, but implicitly wrong).
                                This stands in sharp contrast to PulseAudio, which is not endorsed by the Kernel; that makes me feel warm inside .

                                Comment

                                Working...
                                X