Pulse audio issue when running Snapclient as a service with systemd

[gribouk]

I think you should use two environment files, but I'm not an expert in systemd. But this is not a snapcast issue

Originally posted by @badaix in #809 (comment)

It feels like it is somehow related to a snapclient. After some investigation, I decided not to launch multiple instances of snapclient and test single one. It turns out, that when the device is set to default one, snapclient is unable to connect to a server, below is the log for that:

Feb 20 00:41:07 raspberrypi snapclient[1943]: (Browser) NEW: service 'Snapcast' of type '_snapcast._tcp' in domain 'local'
Feb 20 00:41:07 raspberrypi snapclient[1943]: (Browser) CACHE_EXHAUSTED
Feb 20 00:41:07 raspberrypi snapclient[1943]: Service 'Snapcast' of type '_snapcast._tcp' in domain 'local':
Feb 20 00:41:07 raspberrypi snapclient[1943]: #011tigraresidence-NUC10i7-srv1.local:1704 (192.168.1.246)
Feb 20 00:41:07 raspberrypi snapclient[1943]: Found server 192.168.1.246:1704
Feb 20 00:41:07 raspberrypi snapclient[1943]: Resolving host IP for: 192.168.1.246
Feb 20 00:41:07 raspberrypi snapclient[1943]: Connecting
Feb 20 00:41:07 raspberrypi snapclient[1943]: Connected to 192.168.1.246
Feb 20 00:41:07 raspberrypi snapclient[1943]: My MAC: "dc:a6:32:c5:51:4c", socket: 8
Feb 20 00:41:08 raspberrypi snapclient[1943]: ServerSettings - buffer: 1000, latency: 0, volume: 18, muted: 0
Feb 20 00:41:08 raspberrypi snapclient[1943]: Codec: flac, sampleformat: 44100:16:2
Feb 20 00:41:08 raspberrypi snapclient[1943]: metadata:{"STREAM":"tigra_is_broadcasting"}
Feb 20 00:41:08 raspberrypi snapclient[1943]: Player name: alsa, device: default, description: <none>, idx: 4, sharing mode: unspecified, parameters: <none>
Feb 20 00:41:08 raspberrypi snapclient[1943]: Mixer mode: software, parameters: <none>
Feb 20 00:41:08 raspberrypi snapclient[1943]: Sampleformat: 44100:16:2, stream: 44100:16:2
Feb 20 00:41:08 raspberrypi snapclient[1943]: Using buffer_time: 80 ms, fragments: 4
Feb 20 00:41:08 raspberrypi snapclient[1943]: ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused
Feb 20 00:41:08 raspberrypi snapclient[1943]: Exception: Can't open default, error: Connection refused, code: -111
Feb 20 00:41:08 raspberrypi snapclient[1943]: Exception: Can't open default, error: Connection refused
Feb 20 00:41:08 raspberrypi snapclient[1943]: Snapclient terminated.
Feb 20 00:41:08 raspberrypi systemd[1]: snapclient_speker_wire.service: Main process exited, code=exited, status=1/FAILURE
Feb 20 00:41:08 raspberrypi systemd[1]: snapclient_speker_wire.service: Failed with result 'exit-code'.
Feb 20 00:41:08 raspberrypi systemd[1]: snapclient_speker_wire.service: Service RestartSec=100ms expired, scheduling restart.
Feb 20 00:41:08 raspberrypi systemd[1]: snapclient_speker_wire.service: Scheduled restart job, restart counter is at 5.
Feb 20 00:41:08 raspberrypi systemd[1]: snapclient_speker_wire.service: Start request repeated too quickly.
Feb 20 00:41:08 raspberrypi systemd[1]: snapclient_speker_wire.service: Failed with result 'exit-code'.

As you can see, the error originates from a snapclient. Why?
When the device is not default, the error does not appear.

[kingosticks]

The error is in the log, it's related to pulseaudio. You also said in your other issue (which you could have just reopened?) that the difference between this non-working setup and a previous working setup was the use of Pi OS full desktop, which uses pulseaudio.

Feb 20 00:41:08 raspberrypi snapclient[1943]: ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused
Feb 20 00:41:08 raspberrypi snapclient[1943]: Exception: Can't open default, error: Connection refused, code: -111

Isn't this another instance of #779?

[gribouk]

Thanks for your reply!
Actually, I did not know that it is possible to reopen the issues and did the first thing offered in the menu in the upper right corner of the repply area.

I have read the info in that bracnch. Before the finall step it seemed exactly my case - all the errors were reproduced step by step. But, when I made the changes marked as a solution in that case:

changes to /etc/pulse/client.conf

; default-sink =
; default-source =
default-server = 127.0.0.1
; default-dbus-server =

, everything stopped working completely. Describe it step by step:
Before:
When I call from command line: snapclient -i 3
Client starts
When I call from the command line: systemctl start snapclient.service
Error from my original post
Now:
When I call from command line: snapclient -i 3
Error:

2021-02-20 15-34-50.799 [Info] (Avahi) (Browser) NEW: service 'Snapcast' of type '_snapcast._tcp' in domain 'local'
2021-02-20 15-34-50.800 [Info] (Avahi) (Browser) CACHE_EXHAUSTED
2021-02-20 15-34-50.938 [Info] (Avahi) Service 'Snapcast' of type '_snapcast._tcp' in domain 'local':
2021-02-20 15-34-50.938 [Info] (Avahi)  tigraresidence-NUC10i7-srv1.local:1704 (192.168.1.246)
2021-02-20 15-34-50.939 [Info] (Controller) Found server 192.168.1.246:1704
2021-02-20 15-34-50.939 [Info] (Connection) Resolving host IP for: 192.168.1.246
2021-02-20 15-34-50.939 [Info] (Connection) Connecting
2021-02-20 15-34-50.943 [Notice] (Connection) Connected to 192.168.1.246
2021-02-20 15-34-50.943 [Info] (Connection) My MAC: "dc:a6:32:c5:51:4c", socket: 8
2021-02-20 15-34-51.081 [Info] (Controller) ServerSettings - buffer: 1000, latency: 0, volume: 10, muted: 0
metadata:{"STREAM":"tigra_is_broadcasting"}
2021-02-20 15-34-51.081 [Info] (Controller) Codec: flac, sampleformat: 44100:16:2
2021-02-20 15-34-51.081 [Info] (Player) Player name: alsa, device: default, description: <none>, idx: 4, sharing mode: unspecified, parameters: <none>
2021-02-20 15-34-51.081 [Info] (Player) Mixer mode: software, parameters: <none>
2021-02-20 15-34-51.081 [Info] (Player) Sampleformat: 44100:16:2, stream: 44100:16:2
2021-02-20 15-34-51.081 [Info] (Alsa) Using buffer_time: 80 ms, fragments: 4
ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Connection refused

2021-02-20 15-34-51.084 [Error] (Alsa) Exception: Can't open default, error: Connection refused, code: -111
2021-02-20 15-34-51.084 [Fatal] (Snapclient) Exception: Can't open default, error: Connection refused
2021-02-20 15-34-51.085 [Notice] (Snapclient) Snapclient terminated.

I have tried to indicate the ip of the computer where it is all installed and PulseServer too explicitelly: 192.168.1.247 - same result

When I try to tell --player pulse, I get this error:

pi@raspberrypi:~ $ snapclient -i 3 -s 4 --player pulse
Assertion 'o' failed at pulse/operation.c:133, function pa_operation_get_state(). Aborting.
Aborted

Do you know why this might be happening? Thank you in advance for any help.

UPD: I have checked if PulseAudio server starts when I indicate the default server IP and it does not. Am I missing something?

[kingosticks]

You want

default-server = 127.0.0.1

Also, when running things as a system service they often run as a different user compared to when you run them normally in a terminal. You can see the snapclient service file runs as user snapclient. By default, pulseaudio runs as your logged in user and only accepts connections from programs also running as your logged in user (through Dbus, I guess). You need to tell pulseaudio that it should accept connections from any user on your machine. Try the following: uncomment or add the TCP module to /etc/pulse/default.pa so it looks like:

### Network access (may be configured with paprefs, so leave this commented
### here if you plan to use paprefs)
#load-module module-esound-protocol-tcp
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1
#load-module module-zeroconf-publish

And then restart the machine to ensure it takes effect.

[gribouk]

Thanks for the reply!

I did as you suggested but with no result:

; default-sink =
; default-source =
default-server = 127.0.0.1
; default-dbus-server =

### Network access (may be configured with paprefs, so leave this commented
### here if you plan to use paprefs)
#load-module module-esound-protocol-tcp
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1
#load-module module-zeroconf-publish

when checking the server status

pi@raspberrypi:/etc/pulse $ systemctl --user status pulseaudio.service
● pulseaudio.service - Sound Service
   Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

This thing does not start when I make changes to client.conf I suggest... Why? Is there anything else I am missing? Thanks a alot for helping me with this!

[gribouk]

I wounder why if the command:

pi@raspberrypi:~ $ snapclient -i 3 --player pulse

runs the snapclient ok, the command:

pi@raspberrypi:~ $ sudo -u pi snapclient -i 3 --player pulse

leads to this:
2021-02-20 18-45-30.061 [Fatal] (Snapclient) Exception: Failed to connect to PulseAudio context: Connection refused
2021-02-20 18-45-30.062 [Notice] (Snapclient) Snapclient terminated.

isn't that the command which is OK ran from the user 'pi'?

So calling 'sudo -u pi' should do no difference, shouldn't it?

[kingosticks]

pi@raspberrypi:/etc/pulse $ systemctl --user status pulseaudio.service

That's a user service.... Not sure that is interesting.

So calling 'sudo -u pi' should do no difference, shouldn't it?

When using sudo you get a minimal environment i.e. you don't get all your normal environment variables defined. You can see that in the different output when running env vs. sudo -u pi env. If you read #779 (comment) you can see the different ways pulseaudio tries to find which pulseaudio server to connect to, many of which involve using environment variables. My guess is that it's somehow related to that and for some reason the default-server config is not being using. Could there be some conflicting config in ~/.pulse/client.conf ?

Try running this instead to make the server IP explicit:

sudo -u snapclient snapclient --player pulse:server=127.0.0.1

[gribouk]

Thanks for your reply.
I've been exploring how it works, and was not able to gain any ground thus decided to start from scratch. This time I opted to try Pi Os minimal but work with Pulse Audio insted of ALSA, since I need Snapcast's pipes to be mixed on my RPi - thus I need several clients, each reads it's source, then those are mixed and sent to the speaker - this is not possible with ALSA since it dedicates a speaker to one source at a time only. So I installed everything needed, as usual I did not manage to start any snapserver as a service and did what you suggested initially (the procedure which already worked in that post you redirected me to). And now I am able to start the clients as services, but with errors in connection and no sound they can read from the pipes:

pi@raspberrypi:~ $ sudo systemctl status snapclient.service
● snapclient.service - Snapcast client
   Loaded: loaded (/lib/systemd/system/snapclient.service; enabled; vendor prese
   Active: active (running) since Sat 2021-02-20 22:18:13 GMT; 58s ago
     Docs: man:snapclient(1)
 Main PID: 625 (snapclient)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/snapclient.service
           └─625 /usr/bin/snapclient --logsink=system

Feb 20 22:19:10 raspberrypi snapclient[625]: Resolving host IP for: fe80::aef2:5
Feb 20 22:19:10 raspberrypi snapclient[625]: Connecting
Feb 20 22:19:10 raspberrypi snapclient[625]: Failed to connect to host 'fe80::ae
Feb 20 22:19:10 raspberrypi snapclient[625]: Error: Connection refused
Feb 20 22:19:10 raspberrypi snapclient[625]: Error in socket shutdown: Transport
Feb 20 22:19:11 raspberrypi snapclient[625]: Resolving host IP for: fe80::aef2:5
Feb 20 22:19:11 raspberrypi snapclient[625]: Connecting
Feb 20 22:19:11 raspberrypi snapclient[625]: Failed to connect to host 'fe80::ae
Feb 20 22:19:11 raspberrypi snapclient[625]: Error: Connection refused
Feb 20 22:19:11 raspberrypi snapclient[625]: Error in socket shutdown: Transport
pi@raspberrypi:~ $ sudo systemctl status snapclient1.service
● snapclient1.service - Snapcast client BT 1
   Loaded: loaded (/lib/systemd/system/snapclient1.service; enabled; vendor pres
   Active: active (running) since Sat 2021-02-20 22:18:13 GMT; 1min 3s ago
     Docs: man:snapclient(1)
 Main PID: 624 (snapclient)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/snapclient1.service
           └─624 /usr/bin/snapclient --instance=2 --logsink=system

Feb 20 22:19:16 raspberrypi snapclient[624]: Resolving host IP for: fe80::aef2:5
Feb 20 22:19:16 raspberrypi snapclient[624]: Connecting
Feb 20 22:19:16 raspberrypi snapclient[624]: Failed to connect to host 'fe80::ae
Feb 20 22:19:16 raspberrypi snapclient[624]: Error: Connection refused
Feb 20 22:19:16 raspberrypi snapclient[624]: Error in socket shutdown: Transport
Feb 20 22:19:17 raspberrypi snapclient[624]: Resolving host IP for: fe80::aef2:5
Feb 20 22:19:17 raspberrypi snapclient[624]: Connecting
Feb 20 22:19:17 raspberrypi snapclient[624]: Failed to connect to host 'fe80::ae
Feb 20 22:19:17 raspberrypi snapclient[624]: Error: Connection refused
Feb 20 22:19:17 raspberrypi snapclient[624]: Error in socket shutdown: Transport

What do you think it might be?

Thanks for your time and advise!

[gribouk]

UPD: it did work till first reboot only. Now, after the reboot, the pulseaudio server is inactive and give me this error on restart attempt:

pi@raspberrypi:~ $ pulseaudio --start
N: [pulseaudio] main.c: User-configured server at 127.0.0.1, refusing to start/a                       utospawn.

[kingosticks]

Alsa dmix plugin allows multiple sources at the same time. It just works

[gribouk]

UPD 2: This one does not work either. The PulseAudio does not start now. I cannot make it running. What could happened to it? I commented back those two lines but it does not help...

pi@raspberrypi:~ $ sudo -u snapclient snapclient --player pulse:server=127.0.0.1
2021-02-20 23-20-58.593 [Fatal] (Snapclient) Exception: Failed to connect to PulseAudio context: Connection refused
2021-02-20 23-20-58.593 [Notice] (Snapclient) Snapclient terminated.

[kingosticks]

It would also be better if you just post in one place. Cross posting all this different info in two places is really confusing.

[badaix]

@gribouk your original issue was not at all about PulseAudio, it was about starting multiple instances of Snapclient, and you were putting your command line options to the ExecStart parameter, instead of using the EnvironmentFile, which is even (maybe not that explicit) described in the Readme.
You could also have figured a solution for #805 if you would have inspected the command line options.
I'm just tired of this support crap, it's like hydra, while closing an issue, two new issues are opened, tagged as bug, preferably without any further response or "thanks" by the issue reporter (I'm not talking about you).
Please consider posting questions in discussions. You can also consider using balena sound (no I'm not related with them, still waiting to get starred from them).
And please change the subject to something meaningful.

[gribouk]

1. Please understand, that most often the issues come from the users, whos main occupation is not IT. Mine, for example, originates from the Theoretical Physics (Quantum Field Theory), which is pretty far distanced from the IT. My first experience with Git Hub is happening ... right about now, T minus 3 week maybe. And people, who adddress their problems to you are most likely of that kind - it is natural to appeal for a help if you do not have sufficient experience and stuck with something. Thus:
2. I did not chose that title - it was generated automatically when I picked "reference as a new issue". I did not know it is possible to change the title either, and yes, I had no idea that it is possible to reopen the issues, somehow I did not catch that option in the interface. Neither I had any idea there is a "discussions" branch, only now I have noticed there is such folder in the top menu.
3. I can read the manual and did so. As a metter of fact, you can put options into the ExecStart and everythig works perfectly, with ALSA, not pulseaudio. I have checked either way. So, thechnically, If you keep your EnvironmentFile blank, there would be no problem, that several services would reference it - it is empty, all the options come from the ExecStart - no conflict arrises. But yes, you are right in a way, that it is not as design supposed this feature to be used, but it works no problem. And as you could understand from this branch, the issue was not eventully about several clients, because even single one refused to start when it needed to access the pulse server...
4. Sync problem when multiple clients are run on same device. #805 - my bad, no argue. But I have opened that one because I was investigating network issues for 4 hours to understand why there was a delay, reinstalling stuff and so on, checking my network config... It did not came to my attentions, that one could manually synchronise the streams - so simple... When I opened it, I was thinking there was a real bug.
5. I understand your irritation from dealing with ingnorance in your field comming from the people like me, but you should not take it so close to the heart - it is life (see 1) - experienced developers have sufficient experience to deal with the problems themselves, and most likelly the bug reports here would not be a real bugs, but rather an attempt to attract some attention to the problem people face or the lack of attention, or the lack of knowledge. You have a pretty good product. And I belive it works well, and it is not your fault that some modules used by it do not function as expected halting peoples dreams - we all understand that (at least I do).

P.S. I still did not manage to make pulseaudio working - I guess that none has doubts by this moment that it is a pure pulse server issue, not service file syntax... The recepee provided #779 for some reason does not work for me. But I keep digging - searching the forums, using your product with ALSA meanwhile - and it works great, you've done a exelent job! I am not expecting to have you as a tech support in no way, understanding that the product is free. As an idea, maybe it worth composing some kind of a 'Dummy Q & A" for beginners like me to search for the obvious answeers there (like pulse audio) - just an idea (thogh discussions are fine too, from the other side)... Though I understand that you cannot afford waisting your time on that, maybe someone from the community would do that for the future generations...
P.S.2. Hope the current title fits well...

[gribouk]

Alsa dmix plugin allows multiple sources at the same time. It just works

As I was explained at one of the branches, dmix would not work with bluealsa, so I will not be able to stream multiple streams to BT speakers using that.

But this time I would like to thank you for your valuable directions which were pretty helpfull and share the results of my investigation:

1. I did manage to make pulse server running.
2. I did managed to launch multiple snapclients using my original service.service files (all params in ExecStart).
   But it all came for a price - I have to run pulse audio in a system mode.

I took very strict approach to determining if it is a problem with me, or PiOS/pulseaudio config. The sequence of my actions:

1. Format drive
2. Flash the PiOs full (dated 01.11.2021 - the latest at this moment)
3. Create empty ssh for the first ssh login.
4.  Boot -> login -> sudo raspi-config -> enable ssh -> change password -> save -> exit -> sudo apt update -> sudo apt upgrade -> sudo reboot
5. login -> sudo nano /etc/pulse/client.conf default-server = 127.0.0.1 
    ->sudo nano /ect/pulse/default.pa load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1 -> sudo reboot
6. wget  https://github.com/badaix/snapcast/releases/download/v0.23.0/snapclient_0.23.0-1_armhf.deb ->
    sudo dpkg -i snapclient_0.23.0-1_armhf.deb -> sudo apt-get -f install -> reboot
-----------------
End of story - after the reboot snapclient is in failure state as before with exactly the same error.

I've done the procedure several times to make sure that it is not me adding something which effects the resut. I also tried skiping step 5 to se how it works without intervention into pulseaudio config - same result.
What I try to say that there is somethng out of the box with PiOs/Pulseaudio config that does not seem to be right.
I am using RPi4, 8GB, if you want to doublecheck the results.

So, what I did was to make it run in the system mode using this manual:
https://rudd-o.com/linux-and-free-software/how-to-make-pulseaudio-run-once-at-boot-for-all-your-users
and I had to add this to the system.pa file to make it finally work:
load-module module-native-protocol-unix auth-anonymous=1
Otherwise I just do not see how make it accessible for users.
I was wondering if someone else experiences similar problm with snapclient and pulseaudio in full version?

And yet I do not understand how that case you directed me to initially was solved with "default-server=127.0.0.1" replacement only...

I wanted to ask your oppinion if you would regard running in a system mode acceptible (this is single user machine - pi, only boot and play sond), because pulseaudio developers strongly opposed doing this...

And one more thing I have forgotten to mention: --player=pulse stil not working, only player=alsa.

Is it an isseu or I am missing something again?

Thanks for your replies!

[ssieb]

If you're running an audio application as a root system service, then the pulseadio server has to run as a system service which is fine for a single-use device. If you want to run pulseaudio as a user, then you have to run the audio applications as that user as well. And that user probably has to be in the "audio" group or whatever the equivalent is for your OS.

[kingosticks]

Pulseaudio have kindly documented what's wrong with running it in system mode: https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/WhatIsWrongWithSystemWide/

---

Anyway, I had a go with the latest RPi OS and found the same:

1. Fresh RPi OS Desktop image, all the usual enable ssh stuff plus a full upgrade (sudo apt dist-upgrade) and reboot
2. Installed snapclient 0.23.0
3. Add default-server = 127.0.0.1 to /etc/pulse/client.conf
4. Add load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1 to /etc/pulse/default.pa
5. Reboot.

This would now work OK if you always logged onto the system before trying to actually use snapclient. But, if you've got some kind of headless setup we now run into a load of problems because Pulseaudio runs as a user service. Firstly it means that it doesn't start automatically. I think this is because it wants to use its 'autospawn' feature to start on demand by programs running as the same user. Technically I think we can force it start automatically with systemctl enable --user pulseaudio (and that does seem to work) but I'm not sure what the implications of that are. And the next problem is that user services and system services are totally separate and cannot depend on one another i.e. the snapclient system service has no way it can wait for pulseaudio user service to become ready before starting. Which means after a restart, snapclient still comes up failed:

pi@snapi:~ $ sudo journalctl -u snapclient 
-- Logs begin at Tue 2021-02-23 01:26:18 GMT, end at Tue 2021-02-23 01:28:49 GMT. --
Feb 23 01:26:23 snapi systemd[1]: Started Snapcast client.
Feb 23 01:26:24 snapi snapclient[481]: Assertion 'o' failed at pulse/operation.c:133, function pa_operation_get_state(). Aborting.
Feb 23 01:26:24 snapi systemd[1]: snapclient.service: Main process exited, code=killed, status=6/ABRT
Feb 23 01:26:24 snapi systemd[1]: snapclient.service: Failed with result 'signal'.

And you need to do a manual sudo service snapclient restart to get it going:

Feb 23 01:27:56 snapi systemd[1]: Started Snapcast client.
Feb 23 01:27:56 snapi snapclient[1122]: (Browser) CACHE_EXHAUSTED
Feb 23 01:27:56 snapi snapclient[1122]: (Browser) NEW: service 'Snapcast' of type '_snapcast._tcp' in domain 'local'
Feb 23 01:27:56 snapi snapclient[1122]: Service 'Snapcast' of type '_snapcast._tcp' in domain 'local':
Feb 23 01:27:56 snapi snapclient[1122]:         xps.local:1704 (192.168.1.147)
Feb 23 01:27:56 snapi snapclient[1122]: Found server 192.168.1.147:1704
Feb 23 01:27:56 snapi snapclient[1122]: Resolving host IP for: 192.168.1.147
Feb 23 01:27:56 snapi snapclient[1122]: Connecting
Feb 23 01:27:56 snapi snapclient[1122]: Connected to 192.168.1.147
Feb 23 01:27:56 snapi snapclient[1122]: My MAC: "b8:27:eb:19:50:a0", socket: 8
Feb 23 01:27:56 snapi snapclient[1122]: ServerSettings - buffer: 1000, latency: 0, volume: 100, muted: 0
Feb 23 01:27:56 snapi snapclient[1122]: metadata:{"STREAM":"mopidy_tcp"}
Feb 23 01:27:56 snapi snapclient[1122]: Codec: flac, sampleformat: 44100:16:2
Feb 23 01:27:56 snapi snapclient[1122]: Player name: pulse, device: default, description: Let PulseAudio server choose the device, idx: 1, sh
Feb 23 01:27:56 snapi snapclient[1122]: Mixer mode: software, parameters: <none>
Feb 23 01:27:56 snapi snapclient[1122]: Sampleformat: 44100:16:2, stream: 44100:16:2
Feb 23 01:27:56 snapi snapclient[1122]: Using buffer_time: 80 ms
Feb 23 01:27:56 snapi snapclient[1122]: diff to server [ms]: 3.62983e+08

I don't know you are supposed to get around this, short of also running snapclient as a user service or running pulseaudio as root (horrible). Pulseaudio is a bit of a mess for headless audio players like snapcast and Mopidy. I'm going to stick to the lite image and hope it stays the way it is...

[g-rocket]

@kingosticks from the page you linked (emphasis added)

In most desktop use cases, system mode likely is not the right choice. There are use cases where system mode does make sense, and these are listed further down.
...
System mode is around for usage on thin client or embedded setups, where no real local user exists, where access is exclusively via the network, and where state data is flushed on each session termination.

Running snapclient on a raspberry pi is exactly such an embedded client; in that case it's likely best to run pulseaudio in system mode.

[gribouk]

Thanks! I'll keep in mind if I try to run it in a system mode again. The problem with it was that in a system mode a pulse audio sound quality collapsed (noise, cracks, frequency cuts and ect) and a BT fell off (the primary reason I was attempting to run pulse - to mix sounds before sending these to a BT speaker). So, I solved the issue from the other end without using a BT of a RPi itself, but through a line output, which is later sent to a BT speacker(s) (in some rooms I have up to 4 BT speakers synchronised), and ALSA with its stable sound quality is just enough in this case - works wonderfull...

[g-rocket]

Yeah, pulseaudio is really designed for a single-user linux desktop running gnome + dbus + systemd where the active user is always logged in and you want to control everything with GUIs; anything else is not really very well supported.

[kingosticks]

Raspberry Pi OS desktop image is exactly a desktop system. The lite image you can get away with pretending it's an embedded system but that's not even using pulseaudio so who cares. If you've got a reliable working recipe for the desktop image running snapclient as a system service please share.

[blind-oracle]

@gribouk I'm using RPi4 for watching movies through Kodi and also as a snapclient & server. Because of Kodi I had to use Pulseaudio to share the ALSA device. It works fine in system mode without any cracks or anything, i'm using 24bit/96khz everywhere (HiFIBerry DAC).

The only problem I have is that sometimes when I start playback the sound from the local snapclient gets garbled, in this case it's enough to restart snapclient, so probably it still has some bugs...

[gribouk]

@gribouk I'm using RPi4 for watching movies through Kodi and also as a snapclient & serve...

As mentioned in the discussion above, you're not using it in a "headless mode" (for the reason you use Kodi), whereas all the issue is addressed to the headless mode...

[blind-oracle]

@gribouk What do you mean by headless? If that's the lack of X-server then it's headless.
Kodi is also started as a systemd service and runs directly on GPU in a standalone mode:

# ps ax | grep kodi
  606 ?        Ss     0:00 /bin/sh /usr/bin/kodi-standalone
  621 ?        S      0:00 /bin/sh /usr/bin/kodi --standalone
  655 ?        Sl   243:43 /usr/lib/arm-linux-gnueabihf/kodi/kodi.bin_v8 --lircdev /var/run/lirc/lircd --standalone

In the end nobody's logged in the system and it's the lite image without any desktop crap.

[gribouk]

Oh, now I see what you mean. Had to read this thrice...

When I tried to start in a system mode, the sound quality noticeably droped. And this issue is met in the internet when I tried to google for a solution.

But the biggest challenge was with a BT - it has gone, and a simple solution to get it back was not found. Actually, even if I would have turened it on again into a pulse audio scope, I would not use it anyway because of the codec - RPi does not support Aptx-LL, and not BT speaker does, I would have to use BT transmitters and recievers to buid a network of speakers as I do now anyway...

[blind-oracle]

@gribouk What's the problem with the BT? It's working for me fine, my kid is watching movies in BT headphones.

Pulseaudio switches the sound from speakers to the BT automatically when the headphones connect and back when they are powered off.

As for AptX and friends - I've built these modules https://github.com/EHfive/pulseaudio-modules-bt and now Pulseaudio works with LDAC/AptX/etc. Not sure about AptX LL, but anyway it's better than stupid SBC.

the sound quality noticeably droped

I haven't noticed any difference between playing from snapclient directly to ALSA or through Pulseaudio (in system mode)...

[gribouk]

What's the problem with the BT? It's working for me fine...

Aha, so that's what we have the community for...

The story of ̷m̷y̷ ̷l̷i̷f̷e̷ mine as it was described in the topic above:

1. I could not make snapclient start in an automatic mode after reboot not running pulse audio in a system mode. So, I've found the manual by that url: https://rudd-o.com/linux-and-free-software/how-to-make-pulseaudio-run-once-at-boot-for-all-your-users , and with minor modification to the system.pa file made it run (load-module module-native-protocol-unix auth-anonymous=1)
2. What I observed as an outcome:
   in my speakers: high frequency cut, so it started to sound like me sitting in the carton box. Cracks and loud noise when no sound was sent to a speaker (the later was mentioned to be fixed in V24, but not for V23 I experimented with).
   in my sound config: the BT disappeared from the list of the outputs for pulse audio (browsing the interned I came to a conclusion, that it was a common issue for those attempting to run it in a system mode). There is no problem with BT itself, it is still there - connects and disconnects automatically, but not in the outputs list - you cannot direct sound there. So, having spent few hours in useless efforts to recover this thing I've given up on that (the right thing to do though) and went back to the smallest PiOs with ALSA.

So, quoting other participants on the branch, if you have a recipe how to make pulse audio work stable in a system mode - please share keeping as many details as possible in your manual, I would highly appreciate this, and others, I believe, as well.

Resembling to the codec notice - I was kind of surprised that one can install free software to benefit from the use of a commercial codec, namely AptX, knowing that every device manufacturer is charged for using that one on device basis - 1$ per device, plus entrance fee (not willing to go deep into reasoning about legal grounds of that, maybe my info is not up to the date...). But, if you do not have AptX LL, which I did not notice in the supported codecs list, basically you do not have much difference with SBC. LL stands for Low Latency - they promise the sound would fall behind a source by no more than 40ms (less is possible), while for AptX this number is 5+ times bigger and nearly equals the one for SBC. In practice this means you will never get stable synchronized sound coming from several BT speakers without AptX LL codec, and my application is exactly that case. I like to have 2-4 speakers per room at home and introduction of arbitrary delays relative to a sound source leads to an echo effect... Even if there was an extension for PiOs to add AptX LL to a profile it would not change anything, as I mentioned earlier, since I found no BT speaker on the market supporting AptX LL - you need Apx LL receiver anyway for every speaker. So, I solved the puzzle through Transmitter --> multiple Recievers via AptX LL schema, and Aux input from my RPi as a sound source - ALSA is just fine for that.

That’s in brief what was wrong with BT and system mode…

[blind-oracle]

@gribouk

Well, my environment is like this:

• Pi4 with latest Raspbian Lite (without UI)
• HiFiBerry Zero attached as a sound card (internal disabled), not that it matters much
• Runs snapserver, snapclient (through pulse), Mopidy and Kodi

I'm using BT for two things:

• Send audio to headphones when watching Kodi
• Receive audio from smartphone to stream to Snapserver

So in this case I'm not much worried about BT latency as I'm not using it as an output for Snapclient. For input of audio from BT aptX works fine, there are sometimes some sound issues with BT input which i've not yet tracked, but since I don't use smartphone much as a sound source I didn't bother a lot.

From my perspective using Raspberry Zero W + HiFiBerry Zero (combined cost around 30$) as a Snapclient node with SnapOS installed is much better than the complicated scheme with BT transcievers...

As for system-mode Pulseaudio I'll just list the configs that I use. This way it's currently working fine. Sometimes (once in a few days) Snapclient starts to produce garbled sound - this is solved by its restart. Not sure what's the cause here, probably some interoperability with Pulseaudio, needs investigation.

/etc/pulse/daemon.conf

lock-memory = yes
cpu-limit = no
high-priority = yes
nice-level = -20
realtime-scheduling = yes
realtime-priority = 99
resample-method = speex-float-5
avoid-resampling = false
flat-volumes = no
default-sample-format = s32le
default-sample-rate = 96000

/etc/pulse/system.pa

load-module module-device-restore
load-module module-stream-restore
load-module module-card-restore
load-module module-alsa-card device_id=sndrpihifiberry
load-module module-native-protocol-unix auth-anonymous=1
load-module module-dbus-protocol
load-module module-default-device-restore
load-module module-rescue-streams
load-module module-always-sink
load-module module-position-event-sounds
load-module module-switch-on-connect
load-module module-bluetooth-policy
# Most of these options are only available with https://github.com/EHfive/pulseaudio-modules-bt
load-module module-bluetooth-discover a2dp_config="sbc_cmode=dual sbc_min_bp=53 sbc_max_bp=100 sbc_freq=44k ldac_eqmid=hq ldac_fmt=s24"
load-module module-pipe-sink file=/var/run/pulse/snapcast.fifo sink_name=snapcast format=s16le rate=44100

/etc/systemd/system/pulseaudio.service

[Unit]
Description=PulseAudio Daemon

[Install]
WantedBy=multi-user.target

[Service]
Type=simple

ExecStart=/usr/bin/pulseaudio --system --realtime --disallow-exit --no-cpu-limit
Restart=on-failure

LimitRTPRIO=1000
LimitNICE=-20
LimitMEMLOCK=256M

/etc/default/snapclient

SNAPCLIENT_OPTS="--player pulse --soundcard 0 --sampleformat 96000:24:* --mixer hardware --host 127.0.0.1 --logfilter *:notice"

/etc/snapserver.conf

[server]
threads = 4

[http]
enabled = true
bind_to_address = 0.0.0.0
port = 1780
doc_root = /usr/share/snapserver/snapweb

[tcp]
enabled = true
bind_to_address = 0.0.0.0
port = 1705

[stream]
source = pipe:///var/run/pulse/snapcast.fifo?name=pulse&mode=read&sampleformat=44100:16:2
source = tcp://0.0.0.0:1800?name=computer&sampleformat=48000:16:2
source = alsa://?name=mopidy&device=hw:0,1,0
source = meta:///pulse/computer/mopidy?name=all
sampleformat = 96000:24:2
codec = flac
buffer = 400
send_to_muted = true

[logging]
filter = *:notice

[jkwim]

Since I was going through the whole discussion, thought that you might be interested in finding out out how I managed to run PulseAudio in user mode and also run an application in user mode.

These are just steps for running the already developed app. Some of these steps would eventually end up the application installation script as per developers response to me.

Hoping that you can pick up something to solve your problem:

https://github.com/jkwim/owntone-server/blob/pulse_doc1/README_PULSE.md#user-mode-with-auto-startup-script