PulseAudio 11.0 release notes (draft)
Changes at a glance
- Support for newer AirPlay hardware
- USB and bluetooth devices preferred over internal sound cards
- Bluetooth HSP headset role implemented
- Bluetooth HSP audio gateway and HFP hands-free unit roles can be enabled simultaneously
- Upmixing can now be disabled without bad side effects
- Option to avoid resampling more often
- Option to automatically switch bluetooth profile to HSP more often
- Better latency control in module-loopback
- Changed module argument names in module-ladspa-sink and module-virtual-surround-sink
- Fixed input device handling in module-waveout
- Improved bluetooth MTU configuration (warning! this causes some hardware to not work any more, see the details below for how to fix it)
- Applications can request LADSPA or virtual surround filtering for their streams
- Support for 32-bit applications on 64-bit systems in padsp
Notes for end users
Support for newer AirPlay hardware
Previously the RAOP sink in PulseAudio only supported an older version of the protocol, which is not any more used in newer AirPlay products. Hajime Fujita has been maintaining his own version of PulseAudio (with patches from several other contributors too) that supports also the newer RAOP protocol version. That work has now been merged upstream.
USB and bluetooth devices preferred over internal sound cards
The prioritization of sinks and sources has been changed so that USB and bluetooth devices are preferred over internal sound cards when the user hasn't explicitly configured which device should be the default. This means that after plugging in an USB sound card or connecting a bluetooth device, it's not necessary to manually set the new device as default.
Bluetooth HSP headset role implemented
The HSP headset role allows PulseAudio to act as a bluetooth headset, so it's possible to connect e.g. a phone to a laptop running PulseAudio, and use the laptop's speaker and microphone for calls made on the phone. This is similar to the previously implemented HFP hands-free unit role, which is supported via oFono. The HSP headset role doesn't use oFono.
Bluetooth HSP audio gateway and HFP hands-free unit roles can be enabled simultaneously
Previously, passing the "headset=auto" argument to module-bluetooth-discover would enable the HSP audio gateway role when oFono is not running, and the HFP hands-free unit role when oFono is running (so only one HSP/HFP role would be active at a time). The HSP audio gateway role doesn't really interfere with oFono, so this was changed so that the HSP audio gateway role will be kept available all the time.
The new HSP headset role implementation does interfere with oFono, however, so that will be disabled when oFono is running.
Upmixing can now be disabled without bad side effects
By default, PulseAudio will play a stereo stream to all speakers (except subwoofer) of a surround system. Many people don't like this. It has been possible to disable all remixing by setting "enable-remixing = no" in daemon.conf, but that breaks other use cases where remixing is useful (perhaps the most silly breakage is that mono streams don't play at all, because the system doesn't have a dedicated "mono speaker").
Now it's possible to leave remixing enabled, and only disable (most) upmixing by setting "remixing-use-all-sink-channels = no" in daemon.conf. Mono streams will still be upmixed to front-left, front-right and center channels.
Option to avoid resampling more often
By default, PulseAudio will configure hardware to use 44.1 kHz or 48 kHz sample rate, and if applications use some other rate, their audio is resampled to match the hardware rate. Now it's possible to set "avoid-resampling = yes" in daemon.conf, which will make PulseAudio configure the hardware to whatever rate the application uses (if the hardware doesn't support the application's rate, resampling is of course still done).
The feature is disabled by default, because ultrasonic audio can cause audible distortion in the audible frequency range. See the "192kHz considered harmful" section in this article: https://people.xiph.org/~xiphmont/demo/neil-young.html
Option to automatically switch bluetooth profile to HSP more often
By default, module-bluetooth-policy automatically switches from A2DP to HSP when a recording stream appears that has the media.role property set to "phone". To better support VoIP applications that don't set the property (perhaps because they use the ALSA API that doesn't have the concept of stream properties), module-bluetooth-policy can now be configured to switch to HSP also if a recording stream appears with the media.role property unset.
The feature is controlled by the "auto_switch" module argument for module-bluetooth-policy. Previously the argument was a boolean that enabled or disabled the automatic profile switching. Now the argument's type is integer, with the following supported values:
- 0: disable the automatic profile switching altogether
- 1: enable the automatic profile switching for streams with media.role=phone (this is the default mode)
- 2: enable the automatic profile switching for streams with media.role=phone and streams with media.role unset
To keep backwards compatibility with old configuration files, boolean values are still accepted: "true" maps to option 1 and "false" maps to option 0.
Better latency control in module-loopback
The latency of module-loopback can be configured, but so far it hasn't been very good at actually implementing the requested latency. It used to be so that during startup the latency was rather random, and it would take a long time before the module would adapt to the requested latency. Now the startup latency should reflect the requested latency much more accurately.
module-loopback will now also try to ensure that the configured latency isn't too low, but if underruns nevertheless occur, it will increase the target latency automatically.
Changed module argument names in module-ladspa-sink and module-virtual-surround-sink
The master sink for module-ladspa-sink and module-virtual-surround-sink is now specified using the "sink_master" module argument instead of "master". The reason for the change is to be consistent with other modules that use "sink_master" as a module argument name. The old "master" module argument continues to work for the time being (a warning will be logged), but the old argument may be removed in the future.
Fixed input device handling in module-waveout
The Windows audio module, module-waveout, had pretty broken handling for input devices. The module arguments "device" and "device_name" were used for selecting both the input and output device, but the arguments worked properly only for output. Those module arguments have now been replaced by new arguments: "output_device", "output_device_name", "input_device" and "input_device_name". That allows the input device to be configured properly.
Improved bluetooth MTU configuration
The packet size (a.k.a. MTU, "maximum transmission unit") that PulseAudio uses with the bluetooth HSP profile was previously always configured to be 48 bytes. That worked with most hardware, but some adapters require a different packet size. Now PulseAudio asks the kernel what packet size should be used, which fixes the problem.
However, a new problem appeared: some adapters that used to work with 48 byte packet size don't any more work with the size that the kernel tells PulseAudio to use. If you find that HSP audio stopped working when upgrading to PulseAudio 11.0, you can revert to the old behaviour by passing option "autodetect_mtu=no" to module-bluetooth-discover in /etc/pulse/default.pa. If that fixes the problem, then please report the problem to the BlueZ and/or PulseAudio developers, so that the kernel can be fixed.
Notes for application developers
Applications can request LADSPA or virtual surround filtering for their streams
module-ladspa-sink and module-virtual-surround-sink weren't previously compatible with the module argument interface that module-filter-apply expects from filter modules, but now they are. Another problem was that these two filter modules require arguments that module-filter-apply couldn't figure out on its own. It's now possible to tell module-filter-apply what the filter module arguments should be.
To request LADSPA filtering, set the "filter.apply" stream property to "ladspa-sink" and pass the required module arguments with "filter.apply.ladspa-sink.parameters" (multiple arguments are separated by spaces). Similarly, to request virtual surround filtering, set the "filter.apply" stream property to "virtual-surround-sink" and pass the module arguments with "filter.apply.virtual-surround-sink.parameters".
For documentation on what arguments the modules expect, see the Modules page.
The new module argument passing capability can also be utilized with the modules that module-filter-apply supported before (module-echo-cancel and module-equalizer-sink).
Notes for packagers
Support for 32-bit applications on 64-bit systems in padsp
padsp uses the LD_PRELOAD environment variable to make the wrapped application link to libpulsedsp.so. 32-bit applications on 64-bit systems are problematic, because the correct path to libpulsedsp.so depends on which architecture the application is built for. That means that 32-bit applications don't work, because the library path points to a 64-bit version of libpulsedsp.so. The problem is now solved for systems that use glibc. When the library path contains the string "$LIB", glibc will convert that to the correct directory name depending on the application's architecture.
This is not enabled by default, because the fix doesn't work on non-glibc systems. To enable the fix, pass --with-pulsedsp-location='/usr/\\$$LIB/pulseaudio' to the configure script (this assumes that the prefix is /usr, so adjust the path as needed).