We spoke on IRC. I can confirm that spotify plays in strict mode on Ubuntu 17.10 with pulseaudio (verified with pavucontrol). @j605 is running Arch with pulseaudio and it appears that the snap is having trouble using pulseaudio and falling back to alsa.
For now, I’m going to modify the topic to append ‘on Arch’.
Oh sorry for my wording. I meant to say I installed snapd from Arch repos(version 2.27) and still experience the same error. Audio in my system has no issues.
maciek@corsair:~ snap version
snap 2.30.r282.ge1eddad26-1
snapd 2.30.r282.ge1eddad26-1
series 16
arch
kernel 4.14.6-1-ARCH
maciek@corsair:~
Also tried the LTS kernel 4.9.70-1-lts, got the same results.
I’ve seen the problem with spotify not closing before when using spotify from AUR and with a repacked spotify RPM on Fedora. Albeit, this was with some older version and I don’t recall seeing it recently.
Another thing you can try is run spotify from the console and enable debugging logs and paste the output: PULSE_LOG=4 SNAPD_DEBUG=1 SNAP_CONFINE_DEBUG=1 /snap/bin/spotify
FWIW, libpulse logs I get here are:
Parsing configuration file '/etc/pulse/client.conf'
/etc/pulse/client.conf.d does not exist, ignoring.
Using shared memory pool with 1024 slots of size 64,0 KiB each, total size is 64,0 MiB, maximum usable slot size is 65472
Trying to connect to {55f76458585f45adb352cdec85634ded}unix:/run/user/1000/pulse/native...
SHM possible: yes
Protocol version: remote 32, local 30
Negotiated SHM: yes
Parsing configuration file '/etc/pulse/client.conf'
/etc/pulse/client.conf.d does not exist, ignoring.
Using shared memory pool with 1024 slots of size 64,0 KiB each, total size is 64,0 MiB, maximum usable slot size is 65472
Trying to connect to {55f76458585f45adb352cdec85634ded}unix:/run/user/1000/pulse/native...
SHM possible: yes
Protocol version: remote 32, local 30
Negotiated SHM: yes
@attache If you run it in the terminal (e.g. via snap run spotify), what messages (if any) do you get? Could you please paste them here so that we can analyse this further?
After some discussions in the IRC, snapd is looking at /run/user/1000/snap.spotify/pulse/native for the socket which is not available. Instead of looking at /run/user/1000/pulse/native, it tries /var/run/pulse/native and fails. @mvo suggested creating a symlink to check if it indeed fixes the issue. This workaround fixes the issue so the problem is snapd not looking in the correct directory for the socket. Thanks for the help @mvo and @mborzecki!
$XDG_RUNTIME_DIR is set to /run/user/1000/snap.spotify inside the snap
libpulse tries pulse socket locations in the following order: $XDG_RUNTIME_DIR/pulse/native, /var/run/pulse/native
pulse socket is not available in either location
Surprisingly it works on my system, the logs show that instead of trying $XDG_RUNTIME_DIR/pulse/native libpulse goes to {55f76458585f45adb352cdec85634ded}unix:/run/user/1000/pulse/native, as if $XDG_RUNTIME_DIR was completely ignored.