July 2017

This month saw the release of PulseAudio 10.99.1, i.e. the first release candidate (RC) of 11.0. I’m not sure if there will be another RC. The Intel HDMI LPE fix was not included in the first RC, and it’s not clear if it will be included in the release at all. There still hasn’t been much testing, but one user had problems with the patch, so it doesn’t seem safe to apply it (unfortunately the user with the problem hasn’t responded to requests for more information). I will be getting some HDMI hardware myself soon. I don’t know what HDMI driver that computer will have, but if it doesn’t have the LPE driver, at least I can check that the patch doesn’t break non-LPE systems.

There are several bluetooth related changes in the upcoming release, and I updated the bluetooth wiki page to reflect those changes. Georg Chini wrote the updated oFono section. I also added a section for listing what features have been added in which PulseAudio version.

Georg Chini is working on a new mechanisms for applications to send messages to and receive notifications from modules. Currently it’s quite cumbersome to add module-specific functionality to the client API, and the new messaging API should help with that. I discussed the new API with Georg in some length.

As I noted in last month’s report, the latency reporting functionality in the “simple API” got an improvement, but there was still some weird behaviour. I managed to track down the remaining bug and fixed it. It turned out to not affect only the simple API, but also the normal streaming API. Basically all recording applications have been getting bad latency information if the recording stream has a different number of channels than the recording source. When recording, the latency information is often not very important (except in a recording studio setting, but those use cases usually use Jack anyway instead of PulseAudio), maybe that’s why we haven’t got much complaints about the bad latency reports.

I fixed a bunch of D-Bus message object leaks related to the dbus_connection_send_with_reply_and_block() function that turned out to be prone to such leaks.

The default equalizer sink description contains the description of the master sink, but the equalizer description was not updated when moving to another master sink. I fixed that.

It was reported that if the current card profile is “off”, because none of the outputs are plugged in, the profile doesn’t get automatically changed when plugging in headphones. I made a fix for that.

This post was originally written on 2017-08-06, 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.

June 2017

I finished the Intel HDMI LPE jack detection fix. Since I don’t have any HDMI audio hardware (except Raspberry Pi, but that has too unusual HDMI implementation to count in this case), the patch isn’t tested on real hardware yet. If you have Intel HDMI LPE hardware and you’d like to test, let me know. Also, if you have some other HDMI audio hardware that currently has working jack detection, it would be good to test that the jack detection still works, because the patches affect all HDMI devices.

I made a patch that changes how the default sink and source settings are internally stored by PulseAudio. The previous mechanism didn’t allow the default sink to point to a non-existent sink, which meant that if the user configured a USB device as the default sink, and then unplugged the device, the default sink setting was lost. My patch (not yet applied) removes that limitation, so it should finally be possible to set USB devices as default and have PulseAudio remember that choice.

The pa_simple_get_latency function in the “simple API” hasn’t been working correctly, the latency reports have been jumpy. Ted Ying sent a fix, which is now applied. The code still has some issues, but when I tried to fix them, the latency report behaviour got worse, so I didn’t apply my changes. I don’t fully understand why it’s working as well as it does without my changes, that’s something to figure out at a later time.

I made some improvements to the bluetooth documentation (added some troubleshooting tips and added links to bluetooth specification documents).

I finished fixing the MIPS build of webrtc-audio-processing. The PowerPC build turned out to be broken as well, and I fixed that too.

This post was originally written on 2017-07-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.

May 2017

Release preparations have been going on. The first release candidate for 11.0 probably isn’t far away. There are two blocker bugs open, and neither seems particularly tricky to resolve.

The topic of translation workflow came up. A long time ago we used Transifex, but since it stopped providing good author information in the translation patches, we stopped using it, and since then we haven’t used any translation platform. Translation updates have been submitted as regular patches or plain .po files via the bug tracker or mailing list. There hasn’t been a lot of complaining about this, but translators would probably prefer to use a web platform. I looked into Zanata and Weblate, and Weblate seems like it meets our demands about crediting the translation authors properly, so hopefully we’ll try that out soon.

I fixed a bug in the new default device handling code I made earlier. The default device was not always updated properly when something was plugged in our out.

I started working on fixing the Intel LPE HDMI issues. I made a patch that should prevent PulseAudio from thinking that the HDMI device is an analog output, and fixing jack detection is in progress.

I started updating the alsa recipes in OpenEmbedded. That’s mostly finished, just build testing remains to be done.

This post was originally written on 2017-06-06, 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.

April 2017

The current system of scheduling PulseAudio releases is to freeze the master branch three months after the last release. Those three months have passed, so the focus has again moved to the release preparations. There are release blocker bugs open, so a release candidate has not yet been published. The release notes draft is pretty complete already, so you can check out what will be in PulseAudio 11.0: https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/11.0/

I continued reviewing the big patch set from Georg Chini for improving module-loopback, and did other reviews too.

ALSA has a new driver for Intel HDMI LPE, and it doesn’t currently work with PulseAudio. The biggest issue is that trying to use the driver causes PulseAudio to be killed due to using too much CPU time in a realtime thread. It’s unclear what causes that, but there are some definite issues in PulseAudio that affect the new driver. One of those issues is that an analog profile is created for the card, even though it has no analog outputs. I made a fix for that.

The master sink handling was recently changed in module-ladspa-sink and module-virtual-surround-sink, and some bugs were introduced in the new code. I fixed those issues.

The volume control thing in the Budgie desktop environment sometimes does unwanted profile changes when unplugging headphones, and the sound configuration application in Gnome also is known to do that. Debugging this was annoyingly complicated, so I added some more logging about who’s responsible for profile changes.

I updated the libsndfile recipe in OpenEmbedded, and started to package webrtc-audio-processing, because someone wanted to use the webrtc echo canceller in PulseAudio on OpenEmbedded. The webrtc-audio-processing library fails to build on MIPS, I’m currently trying to fix that.

This post was originally written on 2017-05-06, 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.

March 2017

PulseAudio has a new reviewer! Georg Chini was frustrated with slow reviews, and offered to share some of the workload. More people should do that! Georg’s review work has already been very helpful.

I reviewed a patch from Christian Kellner that inverts the priorities that PulseAudio assigns to sinks and sources. The priorities are used for choosing the default sink or source when the user hasn’t manually selected anything. For some reason PCI sound cards previously had higher priority than USB sound cards, and bluetooth devices had the lowest priority of all. Now the priorities are inverted, which means that when a USB sound card is plugged in or a bluetooth device is connected, that will automatically become the new default sink and/or source.

I reviewed a patch (originally from Wim Taymans, resubmitted by Georg Chini) that adds support for the headset role of the bluetooth HSP profile. This means that now any computer running PulseAudio can pretend to be a bluetooth headset. Similar functionality was already available with the HFP profile, though. The benefits of supporting also the HSP headset role are that some devices might not support HFP (that’s a small set, though), and unlike HFP, HSP doesn’t require oFono between PulseAudio and BlueZ.

The parameter syntax of the “auto_switch” argument of module-bluetooth-policy was changed some time ago. I wrote a patch that adds compatibility with the old syntax, so that old configuration files keep working after upgrading to PulseAudio 11.0.

I fixed a bug in the logic that PulseAudio uses to delay initializing bluetooth devices until all profiles are connected. If a device were to first connect e.g. HSP, and then for some reason disconnect it, and then connect A2DP, a crash would happen.

As usual, I also reviewed some patches that I didn’t report individually above due to not being that noteworthy, investigated bugs, and discussed things on the mailing list, bug tracker and IRC.

This post was originally written on 2017-04-05, 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.

February 2017

Socket activation for root

As explained in last month’s report, systemd’s socket activation should be disabled for the root user’s PulseAudio service. I made a patch for that. It took three iterations, with three different approaches, because the first two (ConditionPathIsReadWrite and ConditionCapability) didn’t work as first imagined. In the end I had to use ExecStartPre to run a command that checks whether we’re root. That’s not ideal, because now the socket unit goes into “failed” state with error messages in the syslog/journal, which may make people think that things aren’t working as they should, but that’s the best solution we could come up with. Felipe Sateler submitted a feature request for systemd to add a better way to make units conditional based on the current user.

Build problem with clang

It turned out that the 10.0 release can’t be built with clang. I made a fix for that, and Arun modified our Travis configuration so that builds are also tested with clang, so a similar problem shouldn’t happen any more in the future.

Access control

I reviewed Wim Tayman’s work on adding access control infrastructure for limiting the range of things sandboxed applications can do in PulseAudio. It’s not yet merged (it was kind of prototype-ish code anyway). Wim has updated the code, and it’s now waiting for another review round.

Improving default device selection

Back in September I made patches for improving the default device handling: among the fixed issues were that a device that is not plugged in (e.g. headphones) could be made the default device when better options exist, and at least the D-Bus interface didn’t always send update signals when the default device changes. Now I got the patches reviewed, and based on the feedback, I submitted the second version of the patch set. The second version turned out to cause crashing in module-dbus-protocol, so I had to make yet another version of the patches. The third version is now waiting for review.

module-loopback improvements

Georg Chini submitted a new version of his module-loopback patch set that among other things fixes the initial latency of the loopback. Previously the initial latency could be much too low or much too large depending on circumstances, and while the module did eventually adjust the buffered amount of audio to match the requested latency, that was a slow process. The patch set is pretty large. I started reviewing it (and the biggest latency issues should now be fixed in git master), but there’s a lot more to be reviewed.

OpenEmbedded stuff

I updated the alsa-lib recipe to the newest upstream release.

I started to look into upstreaming the patches that OpenEmbedded has for alsa-tools. At least one of them seemed trivial. I planned to apply it on a fresh clone of the upstream alsa-tools git repository, and test that it builds (just a routine test – it’s actually obvious to see that the patch can’t cause build problems). It turned out that building alsa-tools is a pain. All the tools are separated in their own build systems, but they also have some dependencies on each other. Running “make” at the top level tries to build everything, but the dependencies are handled in a way that doesn’t work out of the box, and one tool also depends on Qt3, which is deprecated and not available in current distributions any more. I pondered a bit whether I should try to make the build system more sane so that “make” at the top level could actually be expected to work, but I don’t think I’ll spend time on that. I believe the problematic tools are used by very few people, so it’s not really worth the effort to make all of them work. I’ll just patch out some of the tools (like OpenEmbedded and other distributions do also) to be able to build the parts that I’m interested in.

Ross Burton reported that the pulseaudio recipe had started producing warnings about text relocations. It seems that something in Ross’s local configuration triggers the problem, because I couldn’t reproduce it with the default configuration. It seems likely that there’s some bug in PulseAudio, but it remains a mystery how to trigger the bug.

This post was originally written on 2017-03-02, 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.

January 2017

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.

Better remixing

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.

Access control

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

OpenEmbedded stuff

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.