It was reported that if a stream has a long underrun (i.e. doesn’t provide any data to play) and then tries to catch up, PulseAudio doesn’t handle that correctly in certain situations, resulting in some amount of silence being played instead of real audio data. I found out why this happens, but I didn’t fix the bug yet.
If a user manually selects a HDMI profile on a sound card that supports both analog and HDMI outputs, module-card-restore will remember that choice. If the HDMI cable is unplugged while PulseAudio is not running, and PulseAudio is then started, module-card-restore used to select the HDMI profile even though it wasn’t plugged in (and PulseAudio knew that it wasn’t plugged in). I fixed module-card-restore so that it doesn’t any more choose unavailable profiles.
Unloading module-echo-cancel crashed sometimes, because messages that the module sent from one thread to another could be processed after the module had been unloaded, and the message handling code didn’t take that into account. I made a fix for that.
Back in February I debugged crashing related to certain assembly code in PulseAudio. The assembly code was used to figure out the processor model in order to enable processor-specific optimizations. At that time my conclusion was that GCC was probably buggy, but I never got around to filing a bug report. Thankfully “EoD” (I don’t know their real name) now filed the bug, and the GCC developers quickly identified the problem: the assembly code in PulseAudio didn’t take x86-64’s feature known as “red zone” into account, so the bug was in PulseAudio after all. The GCC developers also provided several suggestions for fixing the problem, and it was quite straightforward to make a fix (it turned out that no assembly code was required in the first place, since at least GCC and clang provide the __get_cpuid() function that does what the assembly code used to do).
It was reported that the PulseEffects application didn’t work on KDE. Something was moving the application’s stream to a wrong device. After improving the stream moving logging in PulseAudio, the culprit was found to be module-device-manager. That module is only used on KDE to manage stream routing, which is why the problem was specific to KDE. I fixed the module so that it doesn’t mess with streams that have been routed following an explicit request from the owning application.
One recurring problem with bluetooth headsets is that while PulseAudio correctly detects that the headset supports the HSP profile, no audio gets streamed when trying to use the HSP profile. This is typically a problem in the computer’s bluetooth adapter. It may be missing some required firmware or it may be configured in a way that doesn’t work with PulseAudio. It can be hard to figure out what the underlying problem is, but sometimes a fix is found, and last month a user found a fix for the Broadcom BCM4354 bluetooth adapter. I documented the fix on our bluetooth wiki page.
I updated the PulseAudio, ALSA and LAME recipes in OpenEmbedded to the latest releases.
This post was originally written on 2017-12-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.