Electron-provided audio uses ALSA, phone-calls Pulseaudio/Pipewire

[norpol]

Bug Description

If you run Pipewire without Alsa Signal Desktop:

• outputs call/ringing sound on speaker instead of bluetooth headset
• outputs voice messages and video playback on speaker instead of bluetooth headset
• Video/Audio calls are played back via bluetooth headset.

Steps to Reproduce

1. run Pipewire without Alsa Signal Desktop:

Platform Info

Signal Version:

6.30.1 (Note this bug has been present for ever)

Operating System:

NixOS 23.05

with configuration.nix

services.pipewire.enable = true;
services.pipewire.pulse.enable = true;
services.pipewire.alsa.enable = false;

[scottnonnenberg-signal]

Seems related: https://www.reddit.com/r/voidlinux/comments/yn6ifq/do_i_need_alsa_if_i_install_pipewire/

[norpol]

Thanks for your quick triaging and googling. Alsa is (almost?) always present as far as I understand, back pre-pulseaudio all audio playback clients were directly talking to alsa devices I believe.

With Pulseaudio and later Pipewire, the soundservers would provide a virtual alsa device for clients that weren't supporting pulseaudio - but would still benefit that way of soundserver functionality (aka mixing volume of different devices).

With sophistication of bluetooth devices or other audio playbacks, soundservers (and modules/components) would move more and more of the playback out of the alsa environment (bluez-alsa) into the respective audio servers. This allows pipewire/pulseaudio to modify/control audio codecs or do fewest encoding/decodings as possible.

To me it appears that at the moment Signal Desktop probably relies on different audio playback mechanisms internally, some of which are only supporting Alsa (calling sound, voice message playback and recording) and others (actual voice calls) which are natively using Pulseaudio already.

You can possible observe this behavior by opening pavucontrol and seeing that sometimes Signal desktop will be shown as native and sometimes as alsa client, I believe possible also on pulseaudio only environments too.

[scottnonnenberg-signal]

Yes. Message video/audio playback, voice note recording, and incoming call rings all use built-in Electron-provided audio sources. Calls are separate, as you've discovered. We would like to integrate those in the future.

Unfortunately, this will stay this way until we make a relatively large architectural change.

[norpol]

Thank you. That's totally fine for me. I think having an issue that explains the behavior (and the workaround of ensuring to activate pipewire-alsa and pulseaudio-alsa activated) is sufficient.

#5099 appears to have been a similar issue just reverse (so someone noticed that most of the time alsa only works but some things won't work).

[schmeat]

I am having an issue with my microphone not being picked up in voice notes, but working in voice calls. Is this likely the issue?

https://debuglogs.org/desktop/7.24.1/e9b298ae67be5f497b5d9298c5c56857852e05e941de8d1d17e02c6b41016f49.gz

[jamiebuilds-signal]

@schmeat I don't think this is the correct github issue. Can you create a new issue and please include as much detail as possible about your microphone hardware, OS mic settings, and anything else that may be relevant?

[wallabra]

One issue that might be arising from this is that the setting used for voice calls cannot be reused for selecting a device for voice notes.

Otherwise, it would be pretty simple to enumerate a device ID to pass to MediaDevices.getUserMedia, instead of passing nothing:

Signal-Desktop/ts/services/audioRecorder.ts

Lines 73 to 77 in 92d22d0

	const stream = await navigator.mediaDevices.getUserMedia({
	// TypeScript doesn't know about these options.
	// eslint-disable-next-line @typescript-eslint/no-explicit-any
	audio: { mandatory: { googAutoGainControl: false } } as any,
	});

Without constraints passed by the application developer, Electron will always pick the first device by default, no matter what:

https://github.com/electron/electron/blob/15151c68533f5d8d1c9b57dbd7953e805f7719c9/shell/browser/media/media_capture_devices_dispatcher.cc#L33-L41

I just asked Electron to look into how they determine their own defaults. We'll see how that develops. electron/electron#44502

[wallabra]

Should I open a separate issue here on Signal too? There is a setting for voice calls, but not voice notes, and I assume that they use different audio APIs under the hood, making them unable to just reuse the setting for both., as well as this issue.