For me at least. Lennart please test a bit before releasing 🙂 If you need help with release, feel free to just call me (you have my IRC nick), and I can test a prerelease for you. At least this should keep to a minimum the use of patches for PulseAudio. I have yet to be able to put a copy of it in Gentoo without needing a patch.
Anyway the bump is done, PulseAudio 0.9.8 is available in tree together with the bigger brother 0.9.8-r1 for those of you using baselayout 2 (with the experimental init script, now even more important with the bluetooth USE flag, see later). Most of the keywords were dropped because of the three new dependencies.
The first dependency is mandatory and it’s gnome-extra/gnome-audio. Don’t be afraid, nobody will ask you to install anything GNOME to use PulseAudio if you don’t want to. The package only installs a set of wave audio files that are referenced by the default configuration of PulseAudio for instance for hotplug sounds. As the dep is quite lightweight, I decided to just make it mandatory.
The second dependency is bluez-libs and bluez-utils (the latter just at runtime). This is optional and controlled by the bluetooth USE flag and allows to build the module-bt-proximity module, that allows you to shut down the audio when you walk away from your PC carrying with you your bluetooth enabled phone. Unfortunately it doesn’t seem to work here, as it changes the master volume switch, but the optical output is unaffected by this. Update: Lennart told me to use spdif:0 rather than front:0 as output device (the latter is what HAL discovers automatically); with this change, the muting works. The problem then is that the E61 seems dead and back again many times in a minute…
Here comes useful the new init script. When you enable bluetooth USE flag, PulseAudio adds a dependency over bluez libs and utils, and the old init scripts will depend on bluetooth init script, this means that even if you don’t have a bluetooth device installed, it will start the bluetooth services. The new init script is smarter, and checks if you got the bluetooth proximity module loaded, before asking for bluetooth, this saves you.
Another note about the bluetooth USE flag and bt-proximity before moving to the third dependency: when bt-proximity is enabled, PulseAudio won’t start if you don’t have a bluetooth controller (a dongle) available. This means that you should either leave the dongle always inserted (or have the internal bluetooth always enabled) or disable the module from the configuration. With non-systemwide instances you can load the bt-proximity module at runtime, while with systemwide the module loading is disabled right after bootup.
Ending now with the third dependency, it’s PolicyKit. This is one of the many FooKits that comes out of RedHat/Fedora, and it’s supposedly going to be used instead of pam_limits to get access to high priority and realtime scheduling, but… it’s not well documented (or at all), so if you don’t know how to use it, don’t enable the policykit USE flag. Bugs about those, without a solution or a patch, will be closed as UPSTREAM, you have been warned.
Now the next person who’ll ask me documentation about PulseAudio will be risking my wrath 😉 I’ll be working on something in the next weeks, but I still have to finish PAM guides, and since I left the hospital it has become more difficult to focus on writing those.
And by the way, today’s blackout lasted four hours. The laptop wasn’t completely charged; the cellphone and the iPod were both almost completely out of battery power, I had to connect the last two to the APC UPS that I did shut down before, but when the battery of the laptop was finishing, I did the mistake of trying to charge it on the UPS too… it shut down entirely, seems like the MacBook Pro’s power supply should NOT be used with an UPS. I’m sincerely considering a second battery for the MacBook Pro (15.4) and the cellphone (Nokia E61), so that at least I can keep them active even during blackouts, which aren’t rare at all where I live.
