19.10 - Pulseaudio outputs automatically switching to bluetooth

[joebuntu99]

19.10 is showing an undesirable behaviour not present in 18.04 or 19.04.

In general I send audio from mpd and kodi to my bluetooth speaker and send audio from my web browser and vlc to the onboard audio.

Out-of-the-box behaviour on 18.04 and 19.04 was that on connection audio outputs previously sent to bluetooth would "jump" to bluetooth but audio outputs previously not sent to bluetooth (while connected to bluetooth speaker) would remain sent to onboard audio. While connected new outputs would remember the previous preference i.e. firefox would be sent to onboard as that is where it was previously sent.

In 19.10 on connection all open audio outputs are sent to bluetooth regardless of previous state. Also new outputs default to bluetooth.

This behaviour is less desirable (for me) than previous behaviour. As I have not changed anything in the audio setup I am wondering if it is possible to restore previous behaviour? Any help diagnosing the cause of this change would be appreciated. Thanks.

[CatKiller]

Which device is the default and whether existing audio streams should be moved to a new device are both configurable PulseAudio options. In KDE, which is what I use, those options are exposed through the normal audio setup options. I don't know which options are exposed through the GUI in the desktop environment that Ubuntu Studio uses (Xfce?); you might need to install another PulseAudio configuration application to show those options, or change the config files directly.

[joebuntu99]

Yes, Ubuntu Studio uses Xfce. The configuration options I have available to me are pavucontrol and paprefs. Neither appears to give me a way to affect this particular issue.

Doing a little investigation it appear this module is responsible for the behaviour I desire

module-stream-restore
Since 0.9.11. Automatically restore the volume/mute/device state of streams (configuration is saved in a GDBM database)

• restore_volume
  
  • Restore volume (default to true)
  
  
• restore_muted
  
  • Restore mute state (default to true)
  
  
• restore_device
  
  • Restore the selected sink/source (default to true)
  
  
• on_hotplug
  
  • Since 0.9.16. Recheck streams when new device becomes available. (default to true)
  
  
• on_rescue
  
  • Since 0.9.16. Recheck streams when device becomes unavailable. (default to true)
  
  
• fallback_table
  
  • Since 2.0. File name for a fallback table, containing stream-restore entries (with volume only). The file name can be absolute or relative to the configuration directory. When module-stream-restore is loaded, each fallback entry is saved to the database if that entry didn't already exist. The original purpose was to have a way to configure initial volumes for streams already before the first boot. If this argument is not specified, "stream-restore.table" will be loaded if it happens to exist (by default it doesn't). The file format is explained in the example file.

Running

pacmd list-modules

reveals it is loaded with defaults.

index: 1
name: <module-stream-restore>
argument: <>
used: -1
load once: yes
properties:
module.author = "Lennart Poettering"
module.description = "Automatically restore the volume/mute/device state of streams"
module.version = "13.0"

An experiment:

With bluetooth speaker connected I have 3 audio output streams: mpd, firefox, vlc.
Using pavucontrol I send mpd to bluetooth, firefox to onboard audio, vlc to onboard audio.
I disconnect the bluetooth speaker.
As expected mpd is now sent to onboard audio.
I reconnect the bluetooth speaker.
All three output streams are automatically sent to bluetooth speaker.

Here the expected behaviour given the setup is that mpd is "restored" to the bluetooth speaker but vlc and firefox remain at onboard audio.

Further experimentation shows that upon changing the "fallback output" in the pavucontrol output tab all audio streams are switched to that output. This is also unexpected behaviour and not previously the case.

[CatKiller]

So from your description it seems that the fallback table isn't being used for some reason, and so all the streams are being directed to the fallback (default) device when that becomes available again.

[CelticWarrior]

Just a comment, not intended to help you with this "problem":

That behavior is undesirable for you but is actually expected for the vast majority of users, regular users. Those, like me, when pairing/connecting a Bluetooth audio device, expect to use it immediately. That's how Windows, MacOS, iOS and Android behave.

[joebuntu99]

Just a comment, not intended to help you with this "problem":

That behavior is undesirable for you but is actually expected for the vast majority of users, regular users. Those, like me, when pairing/connecting a Bluetooth audio device, expect to use it immediately. That's how Windows, MacOS, iOS and Android behave.

Well I did initially say

This behaviour is less desirable (for me) than previous behaviour

Also I do expect to use bluetooth immediately - for audio streams I output to bluetooth.

And it seems the behaviour I desire is a generally desired behaviour as it is the default behaviour provided by the module module-stream-restore which was loaded by the default setup.

This is not a failure of a custom setup but a seeming failure of the default setup.

So "thanks" for your "comment" I'll get back to attempting to fix my "problem".

[joebuntu99]

So from your description it seems that the fallback table isn't being used for some reason, and so all the streams are being directed to the fallback (default) device when that becomes available again.

I agree it appears that the fallback table and/or the stream-restore database are not being used.

However I have no idea why or where to go from here. I cannot find either table or database if they indeed exist.

This behaviour began after I upgraded from 19.04 to 19.10 using the command do-release-upgrade.

I might try posting in the multimedia section. (edit: ooops, did that, not allowed, silly me.)