Current implementation of Pulse Audio backend unconditionally calls pulseaudio::Client::from_env, which in turn looks for the Pulse Audio server socket only based on some environment variables.
This is a problem, when the path to the server is not set in an environment variable, but via the pulse-client config file ( https://man.archlinux.org/man/pulse-client.conf.5.en - key default-server ). This setting is currently ignored, which makes cpal to either connect to a wrong server instance, or not connecting at all.
In my opinion, processing of the config file logically belongs to the pulseaudio crate. However, because it leads to an unexpected behavior of cpal, and one could also claim that cpal could technically parse the config file itself, I decided to open issues for both cpal and pulseaudio crates (pulseaudio issue: colinmarc/pulseaudio-rs#8)
Current implementation of Pulse Audio backend unconditionally calls
pulseaudio::Client::from_env, which in turn looks for the Pulse Audio server socket only based on some environment variables.This is a problem, when the path to the server is not set in an environment variable, but via the pulse-client config file ( https://man.archlinux.org/man/pulse-client.conf.5.en - key default-server ). This setting is currently ignored, which makes cpal to either connect to a wrong server instance, or not connecting at all.
In my opinion, processing of the config file logically belongs to the pulseaudio crate. However, because it leads to an unexpected behavior of cpal, and one could also claim that cpal could technically parse the config file itself, I decided to open issues for both cpal and pulseaudio crates (pulseaudio issue: colinmarc/pulseaudio-rs#8)