Page 6 of 17 FirstFirst ... 4567816 ... LastLast
Results 51 to 60 of 161

Thread: Systemd 199 Has Its Own D-Bus Client Library

  1. #51
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    Quote Originally Posted by Ericg View Post
    Buffers, zero-copy architecture, efficient CPU usage. A few months back someone ran a few tests using Pulseaudio vs whatever Android's audio layer is (im blanking on the name.) Pulse had fewer wakeups during audio thanks to efficient buffer management and the fact it was more memory efficient, therefore more power efficient. Its not a matter of the drivers themselves and the HARDWARE power management, its the effect on the CPU and how often its causing wakeups and making the CPU kick up from idle. You can look up the full article on how the tests were run and what each test measured / showed on lennarts blog.
    Pulse Audio and efficient CPU usage don't belong in the same country. Let alone the same sentence.

    EDIT: I mean that must be a blatant flat out lie. There's just no way that you could -not- know how wrong that is.

  2. #52
    Join Date
    Jul 2011
    Posts
    363

    Default

    Quote Originally Posted by Teho View Post
    Same goes for socket based boot up as you can discover here. I would assume that same goes for cgroups too; or can you just set cgroup attributes on runtime by using something like this "systemctl set-cgroup-attr foobar.service cpu.shares 2000"? Not only that but systemd supports dependency based service startup and I'm not exactly sure what you mean by strict separation of configuration and shell and transparent networking and so on. I remain somewhat skeptical that those are things that you couldn't do with systemd.
    Systemd is like that. They don't have any dependency on a shell so the configuration has always been separated in Systemd. That line about separation in the configuration from the shell probably is tailored against the old shell based inits. It smell copy past from some sort of openrc propaganda material...

  3. #53
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,876

    Default

    Quote Originally Posted by duby229 View Post
    Pulse Audio and efficient CPU usage don't belong in the same country. Let alone the same sentence.

    EDIT: I mean that must be a blatant flat out lie. There's just no way that you could -not- know how wrong that is.
    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)

  4. #54
    Join Date
    Jul 2010
    Posts
    593

    Default

    Quote Originally Posted by Ericg View Post
    A few months back someone ran a few tests using Pulseaudio vs whatever Android's audio layer is (im blanking on the name.)
    Here's the blog post (PulseAudio vs. AudioFlinger: Fight!). It's already over year old though.

    Quote Originally Posted by duby229
    Pulse Audio and efficient CPU usage don't belong in the same country. Let alone the same sentence.
    It's one of its key design goals. It's also why it could be used in Maemo/MeeGo/webOS... mobile platforms. Here's a blog post showing power savings over plain ALSA with PulseAudio.

    Quote Originally Posted by frign
    And? I never stated to evaluate it; I pointed out configuration and code was separated.
    Well you can separate the ExecStart=, ExecStop=, WantedBy=... lines of other configuration lines by adding a ".../foobar.service.d/*.conf" file if you so desire.

  5. #55
    Join Date
    Oct 2012
    Location
    Cologne, Germany
    Posts
    308

    Lightbulb clearing things up

    Quote Originally Posted by Teho View Post
    Who exactly gets to decide what are the "real" intentions of the project? Kay Sievers has been the maintainer and has done most of the udev developement since 2004. He's also the one who merged the project to systemd. Greg Kroah-Hartman who started the project in 2003 has also been supportive of the move. Those two developers have done something like 85 to 90% of udev developement in the past nine years; mostly Kay though. Also udev is still supported outside of systemd.

    Where?

    Could you show the breakdown of that 132k lines of code? What optional dependecies did you include?

    No it isn't. Some of the key parts like mixing isn't done in kernel by Jack, ALSA (dmix) or PulseAudio. Here's a blog post about saving power by using PulseAudio.

    What exactly are you saying? Both Jack and PulseAudio use the ALSA userspace libaries to talk to the kernel ALSA drivers. I have no idea what you mean by how Linux-devs might be looking at PulseAudio.

    What I meant by security was this:



    It's something that Jack to my understanding doesn't do.
    Valid points, I agree.

    Looking at security, Jack is actually dependent on HRT's, which means, that we also are bound to runaway-timers when we are talking about low-latency-daemons like Jack.
    PulseAudio doesn't have such a low latency and thus doesn't have to entirely depend on those things. But this is a qualitative issue you have to live with when you aim at having a low-latency-system, I don't really see the issue here.

    In regards to Kernel-development, I was speaking of the Jack-integration. Show me where PulseAudio is explicitly and not implicitly implemented into the Kernel and we can talk on in this regard.

    Looking at power, the number of interrupts is highly dependent on how you configure your Kernel. My Kernel currently runs on 33 MHz (8 Cores) and has a _very_ low power-consumption when idling.
    I can only guess in this regard, but PulseAudio performs better in this regard because most users have a low-latency Desktop with a high Timer-frequency and HRT's, ultimately rendering the ALSA-drivers dependent on these high interrupt-rates.

    The number of lines of code were taken from the Wikipedia article after quick-lookup. These numbers may be inaccurate, granted, but it is out of question OpenRC is a way simpler approach than systemd, given the high number of "outsourced" functionality.

  6. #56
    Join Date
    Oct 2012
    Location
    Cologne, Germany
    Posts
    308

    Question open questions

    Quote Originally Posted by Teho View Post
    Here's the blog post (PulseAudio vs. AudioFlinger: Fight!). It's already over year old though.

    It's one of its key design goals. It's also why it could be used in Maemo/MeeGo/webOS... mobile platforms. Here's a blog post showing power savings over plain ALSA with PulseAudio.

    Well you can separate the ExecStart=, ExecStop=, WantedBy=... lines of other configuration lines by adding a ".../foobar.service.d/*.conf" file if you so desire.
    You really got to explain why this can even be possible. I am really wondering how a subset of PulseAudio can be less efficient than PulseAudio itself. Articles authored by Lennart Poettering himself are not that quite convincing.

  7. #57
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,049

    Default

    Quote Originally Posted by frign View Post
    You really got to explain why this can even be possible. I am really wondering how a subset of PulseAudio can be less efficient than PulseAudio itself. Articles authored by Lennart Poettering himself are not that quite convincing.
    The Meego blog posts IIRC say why: Pulse configures the driver to have larger buffers than by default.

    As a RT user you know what that does to latency, but it also saves power.

  8. #58
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,876

    Default

    Quote Originally Posted by frign View Post
    You really got to explain why this can even be possible. I am really wondering how a subset of PulseAudio can be less efficient than PulseAudio itself. Articles authored by Lennart Poettering himself are not that quite convincing.
    Pulse is all about configuration frign. You can configure it to realtime like JACK and raise power usage, or you can configure it to be high-latency and lower power usage. Whats not to understand? (Serious question, I dont understand the part you arent understanding so if you could be more specific / point out specific parts of the articles, thatd be helpful)

  9. #59
    Join Date
    Sep 2012
    Posts
    663

    Default

    About pulse being buggy or CPU hungry, or having hiccups:
    My phone, 3 years ago, with 256MB of ram and 500GHz of cpu ran music and phone calls without any problem. With pulse. So you could route sound to speaker, headphones, or bluetooth any time, and keep different sound volumes for different output or different programs.

    I haven't tried to do that with alsa, and neither did Nokia. Maybe it was possible, probably it wasn't (or they wouldn't be including it in their custom phone distro).
    In any case, it ran fine and did not skip.

    So if it hiccups on your desktop, well, either it's 15 years old hardware at least, or there is something wrong with your setup.

  10. #60
    Join Date
    Jul 2010
    Posts
    593

    Default

    Quote Originally Posted by frign View Post
    The number of lines of code were taken from the Wikipedia article after quick-lookup. These numbers may be inaccurate, granted, but it is out of question OpenRC is a way simpler approach than systemd, given the high number of "outsourced" functionality.
    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.

    Quote Originally Posted by frign View Post
    In regards to Kernel-development, I was speaking of the Jack-integration. Show me where PulseAudio is explicitly and not implicitly implemented into the Kernel and we can talk on in this regard.
    Could you point me where the kernel part of Jack is? ...and how exactly does it make Jack better than PulseAudio.

    Quote Originally Posted by frign View Post
    Articles authored by Lennart Poettering himself are not that quite convincing.
    Neither of the articles I linked were authored by Lennart.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •