This Time Self-Hosted
dark mode light mode Search

Planning for PulseAudio

Thanks to Betelgeuse I finally have audio again on Yamato (again, thanks! — on a different note, this actually made me find out that there absolutely is a bug in ALSA that causes mmap to kill PulseAudio both with the ICE1712 and the HDA drivers), so I’m resuming my duty as PulseAudio maintainer. This is the reason why PulseAudio jumped to version 0.9.15-r50 in ~arch. So what’s up with that?

My current plans in respect to PulseAudio are trying to get 0.9.15 in stable to replace the ancient 0.9.9. What has stopped PulseAudio to go stable up to this point has been exactly two dependencies: OpenRC and libtool 2.2. Originally, the idea was to keep PulseAudio only compatible with OpenRC and no longer with baselayout 1; it was supposed to go stable pretty soon and the baselayout 1 init script was so scarily incomplete that we simply preferred not have to support it.

Unfortunately, there is still no date for OpenRC to go stable, if it’ll go at all in its current form. At the same time, Lennart has seriously warned against system wide mode (even though there are still valid use cases for which Gentoo often is used!) so keeping the new versions off from stable for a “minor” feature that is not even recommended to be used sounds like a bad plan.

For this reason I’ve now split the ebuild in two versions: one will keep the system mode support, with the system mode warnings, the init script and all the niceties, and the other won’t, and won’t depend on OpenRC at all; the latter is what is supposed to go stable and what stable users should locally unmask if they want PulseAudio.

Let me state again: if you want newer PulseAudio and you’re in stable explicitly request the -r1 version, not the -r50!.

Unfortunately while I should be able to ask for stable right away for what concerns time and bugs, there are a few dependencies, which include libtool 2.2 which is not stable yet (and I think it should be, the tinderbox haven’t found many libtool 2.2 bugs lately and quite a few packages started requiring that, rather than just a generic libtool that 1.5 is compatible with).

I still have no real plans for the realtime support; while Lennart released rtkit (does anybody find it concerning that Linux started having packages with names vaguely similar to those from Apple’s OS X?), it needs a patched kernel, which means I should probably be pestering our kernel team to get those patches included before we can actually provide it, even optionally.

This week I hope to be able to work on mpd too, so that the Gentoo packaging plays nice with PulseAudio (right now the fact that you have to run it with a different user forces you to use a systemwide instance).

Comments 8
  1. Do you have plans to get the “critical patches” that upstream is too lazy to make a release (or patch tarball) for into portage?Because the major reason why the PA experience in Gentoo is unsatisfactory for a lot of users is that other distros include those patches and we don’t.

  2. I’m going to help to do a release, for sure, if Lennart is okay with that. But for that I also want to fix up a few details for the BSD port.I’m currently not at home (Nokia E-series for the win), but I’ll resume working on it tonight, if the 7.2 upgrade goes well.

  3. the *kit packages in apple OSes have their historical roots in the Nextstep operating system, and I think this is very good background for the new linux packages, if they had not only the cool names, that is…

  4. Having a stable pulseaudio-0.9.15 is exciting. Since I just changed to use SELinux enabled hardened gentoo, I was eagerly to see a SELinux supported OpenRC, since OpenRC is masked for SELinux rules are not ready. Many people need pulseaudio hardly. But I experience a compilation error of currently pulseaudio-0.9.9 with gcc-3.4. Now everything might go fine.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.