Systemd 199 Has Its Own D-Bus Client Library

[duby229]

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.

[Akka]

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...

[Ericg]

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)

[Teho]

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.

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.

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.

[frign]

clearing things up

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.

[frign]

open questions

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.

[curaga]

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.

[Ericg]

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)

[erendorn]

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.

[Teho]

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.

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.

Articles authored by Lennart Poettering himself are not that quite convincing.

Neither of the articles I linked were authored by Lennart.