PulseAudio 10.0 is out!
The first release candidate for PulseAudio 10.0 was published in the beginning of January. There weren’t many problems with the RC, so this time the first release candidate turned out to be also the last. The final version was released on 2017-01-19. Here are the release notes in case you haven’t seen them yet: https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/10.0/
Bluetooth MTU problems
I merged a patch that was supposed to fix bluetooth HSP audio with some bluetooth adapters that don’t work with the hardcoded audio chunk sizes (a.k.a. MTUs) that PulseAudio has traditionally used. Now PulseAudio asks the appropriate chunk size from the kernel, but it turned out that the change breaks audio with some adapters that used to work with the hardcoded chunk sizes. The situation is difficult: the patch does the right thing in theory, but it’s not clear if it does more harm or good in practice. In the long term I think it’s best to keep the patch and cooperate with the kernel developers to add fixes (or workarounds, if it’s the hardware’s fault) in the kernel so that the kernel gives working parameters for all hardware. I can only hope that the patch won’t cause huge havoc on bluetooth users once it gets more widely used.
Crashing in x32 environments
I did some investigation about crashes in ORC code when running PulseAudio in an x32 environment. It’s likely an ORC bug, but I nevertheless set up an x32 environment and did some investigation in order to be able to make a good bug report for ORC developers. I didn’t get very far in my investigation, however, because if I built PulseAudio without optimizations, PulseAudio would crash already at startup when querying the CPU model, and looking into that problem distracted me from the ORC crash. The CPU querying crash happened inside assembly code, and I’m not fluent at reading x86 assembly code (nor any other architecture assembly code for that matter), but after struggling for some time I figured out why the crash happens. It looks like a compiler bug to me, but I’m not sure. In any case, I should report the problem to the GCC developers.
I don’t report all patch reviews here, but one of the more interesting patch sets was the one from David Mandelberg that added the “remixing-use-all-sink-channels” option to daemon.conf. If you have a surround speaker setup, PulseAudio by default has always used all speakers for playing back stereo audio. There are good reasons why some people don’t like that, but the only way to avoid that has been to disable all remixing, and that would break some use cases, such as trying to play mono audio (since no speaker is designated as a “mono” speaker, mono audio would just not play at all). Now it’s possible to leave remixing on, but set remixing-use-all-sink-channels to “no”, which changes remixing so that stereo audio is only played to the two front speakers, while mono audio is handled in a sane way (mono is actually a special case with special handling, but more generally if the audio input has channels that don’t have a corresponding channel in the output setup, then those channels get remixed to other channels, but if the output side has channels that don’t exist in the input, then those output channels get silence).
Combine sink improvements soon?
I reviewed a patch that made it possible for clients to dynamically add and remove outputs on a running combine sink. I had to reject the first version, but hopefully Steffen Pfendtner will continue working on it. People request this feature every now and then.
RAOP patches merged
It was discussed earlier that it would probably be a good idea to merge the big RAOP sink patch set from Hajime Fujita, Martin Blanchard and Colin Leroy without full review, because nobody seems to find the time to review the patches (the patches have existed for years), while the existing RAOP sink implementation is becoming obsolete, since it doesn’t support newer hardware. That has now happened – PulseAudio 11.0 will have much better RAOP support.
Socket activation for root
I noticed that systemd had created a pulseaudio socket for root on a user’s system (this came up while debugging a different problem), which is not a good thing. For some background: before PulseAudio started to use systemd’s socket activation, PulseAudio had a mechanism for automatically starting the server if it’s not running when a client tries to connect to it. That autospawning mechanism is still used when necessary, but it’s not used if a distribution uses the socket activation mechanism. The old autospawning mechanism is not used for root, because automatically starting PulseAudio for root messes up audio for regular users, because the alsa device handover doesn’t work for root. The systemd socket activation doesn’t currently have similar protection, however. We need some way to disable the socket for root, and I started a mailing list thread asking for ideas. Ahmed S. Darwish and Felipe Sateler had some ideas, and while systemd doesn’t provide a straightforward way to do this, it seems that there are ways to make this happen.
Crash with more than 32 channels
PulseAudio has a limit of 32 channels per device or stream. That’s rarely a problem, but there are some sound cards that have more channels than that. A user of one of such cards reported that PulseAudio crashes when the card is plugged in. I made a fix for the crash, but such cards still can’t be used by PulseAudio. There was some talk about adding better support for such cards, but it doesn’t seem likely that anyone is going to work on that.
High sample rates
Here’s another interesting patch that I reviewed: In the default configuration PulseAudio will configure the sound card to only use 44100 Hz or 48000 Hz sample rate. Some people want to configure the sound card to use higher sample rates to avoid resampling when playing content with high sample rates. It has always been possible to do that, but only in an inflexible way: it was only possible to configure two rates to be used. Arun Raghavan made a patch that added the “avoid-resampling” option to daemon.conf. Setting that option to “yes” will make PulseAudio configure the sound card to use whatever rate the content has that is being played back.
Wim Taymans requested comments about his work on adding infrastructure for doing access control within PulseAudio (for example, disallowing microphone access for untrusted applications). I started looking into it, but I didn’t have time to go through it all. I will continue the review soon (I hope).
On the OpenEmbedded front, I updated the alsa-tools, flac and pulseaudio recipes to use the newest upstream releases.
This post was originally written on 2017-02-04, and first made available to my Patreon supporters. Speaking of Patreon – I’m using crowdfunding in an attempt to make it financially sustainable to continue my volunteer work as a PulseAudio maintainer. If you’d like to help, check out my Patreon page.