PulseAudio Now Supports The Systemd Journal

[DebianLinuxero]

Pulseaudio would be a marvelous piece of software engineering ...

... but not every aplication have support for it. And those, generally take problems because of the fight with PA.

For example, Timidity and Timidity++.

At least, in Debian, you have to manually add an entry in the Gnome startup services to launch it, because it doesn't start normally at boot, even if you configure it as a service; and doesn't run in the shape it should be (don't appear as a device in the Gnome audio properties).

Timidity programmers : please, add support for Pulseaudio.

[Candide]

Disillusioned with Pulseaudio

If you'd asked me a week ago, I'd say this is great news. But about three days ago, I finally had it with Pulseaudio and purged it from my Debian system. I now rely on Alsa for sound.

Let me say that I'm not resistant to change. If a programmer comes up with a great new way of doing things that improves Linux performance, security or stability, then I'm all for it. Until recently I never had a problem with Pulseaudio, and was surprised by all the hatred being piled on it.

But then it happened - after a system update, sound on VLC was broken. I thought that maybe I'd done something wrong, and spent two days looking for a solution. I spent a lot of time searching on Google, and found others who had the same problem. All kinds of fixes were suggested, none of which worked...until someone suggested dumping Pulseaudio. I did that, and magically the issue went away.

Subsequent research into Pulseaudio vs Alsa leads me to conclude that Pulseaudio is a complicated kludge that was never necessary. Sound quality with Pulseaudio is no better than Alsa. Pulseaudio has a few new features which I never use anyway: ability to play over network speakers, can run as a daemon (why is that important?).

I don't have SystemD (it's not part of a standard Debian install). I did download and install Fedora 19 into a spare partition a few months ago to see what it's like. There was no speed improvement on bootup (the supposed great advantage of SystemD), and I was really annoyed that it didn't support dual monitors (not that this has anything to do with Pulseaudio or SystemD as far as I know). The one thing I did like about Fedora was Selinux (I'm a big fan of security). But my overall impression of Fedora wasn't that great and I didn't keep it.

Anyway, I would like to hear a good argument for why we really need Pulseaudio or SystemD. Nothing I've read so far has persuaded me, and my real world experience with these two complicated technologies has been even less persuasive.

[Teho]

Anyway, I would like to hear a good argument for why we really need Pulseaudio or SystemD.

Those things have been argued over numerous times on this forum and elsewhere. It's also completely offtopic so how about you do a little research first (here's a hint, start from here on systemd) and then start a new thread or something?

[uid313]

Soon it wont be GNU/Linux, it will be Poettering/Linux.

systemd will require udev, logind and journald and PulseAudio.
udev will require systemd, logind, journald and PulseAudio.
logind will require udev, systemd, journald and Pulseaudio.
journald will require udev, systemd, logind, and PulseAudio.
PulseAudio will require udev, systemd, logind, journald.

Then Lennart Poettering will create something new and it will depend on everything and everything will depend on it.

[Teho]

Then Lennart Poettering will create something new and it will depend on everything and everything will depend on it.

No they do not... systemd doesn't even have that many non-optional dependencies). It pretty much boils down to glibc and libcap. Also systemd only depends on systemd-udev and systemd-journald, everything else is optional.There's nothing _anywhere_ suggesting PulseAudio would ever depend on systemd and even less so the otherway around... Also considering that the only libc that systemd supports is glibc I think it's fair to leave the GNU in...

[AnonymousCoward]

... but not every aplication have support for it. And those, generally take problems because of the fight with PA.

For example, Timidity and Timidity++.

At least, in Debian, you have to manually add an entry in the Gnome startup services to launch it, because it doesn't start normally at boot, even if you configure it as a service; and doesn't run in the shape it should be (don't appear as a device in the Gnome audio properties).

Timidity programmers : please, add support for Pulseaudio.

Is timidity mandatory? Fluidsynth seems to have native pulseaudio support, at least going by its useflags.

[AnonymousCoward]

As a side note, is it possible to configure the equivalents of period_size, buffer_size with pulseaudio, using the newer tsched scheduler? Even better if I can create a seperate device with these changed parameters, much as can be done with Alsa. Some games sound crackles/pops a lot when not given quite large buffer/period size. This does increase latency, however, so an app-specific way would be ideal. At the moment I kill pulseaudio when playing these games and point them to a "high delay" alsa device.

BTW I can't use tsched=0 as it performs horribly with my card (Xonar Essence STX).

[Ericg]

can run as a daemon (why is that important?).

Just answering this one because I had the link on-hand, also the other ones have frankly been talked to death....

http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/SystemWide/

[curaga]

Have you tried systemd in any of your systems??

No, I only accept good software on my systems.