PDA

View Full Version : squeezelite / PulseAudio / Debian



W69
2018-03-20, 14:33
Hi all!

I'm new to this and pretty much impressed about LMS and its capabilities.

I installed LMS on a RasPi - works fine.

To test the server, I installed squeezelite on my desktop as well as on a laptop.
Both run Debian jessie (oldstable), so the current version provided by the repos is 1.6.4-1.
(By the way: there are 2 packages: "squeezelite" and "squeezelite-pa" ... you can only chose one of these! I chose "squeezelite"...)
First, everything went very well, I could access the LMS web interface and play sound on both clients.

The next day, things changed. Obviously, squeezelite is fired up before networking is completely up and running, so both clients have had MAC address 00:00:00:00:00:00. I resolved the issue by adding something like SB_EXTRA_ARGS="-m 12:34:56:78:90:12" (using the correct MAC addresses) to /etc/default/squeezelite. That solved the issue.

Now, I discovered, that both machines do EITHER play sound through any other app (youtube in a browser or any music player you can think of) OR through squeezelite. Stopping the squeezelite daemon lets all other applications play sound again, restarting the daemon blocks sound for all other applications...

Stopping the daemon and manually restarting squeezelite by invoking (as normal user!)

squeezelite -n name -m 12:34:56:78:90:12 -z
DOES however work as expected - any application can play sounds, including squeezelite!

Adding SB_EXTRA_ARGS="-m 12:34:56:78:90:12 -o pulse" (and logging) leads to the following behaviour, when run as a service:

[22:23:45.544636] test_open:124 playback open error: Connection refused
[22:23:45.544698] output_init_common:373 unable to open output device



Using "top", I observed the daemon is run as root. So I added root to groups audio, pulse and pulse-access - no luck (didn't expect it anyway).

Might be worth posting:

$ squeezelite -l
Output devices:
default - Playback/recording through the PulseAudio sound server
null - Discard all samples (playback) or generate zero samples (capture)
pulse - PulseAudio Sound Server
sysdefault:CARD=NVidia - HDA NVidia, ALC883 Analog - Default Audio Device
front:CARD=NVidia,DEV=0 - HDA NVidia, ALC883 Analog - Front speakers
surround21:CARD=NVidia,DEV=0 - HDA NVidia, ALC883 Analog - 2.1 Surround output to Front and Subwoofer speakers
surround40:CARD=NVidia,DEV=0 - HDA NVidia, ALC883 Analog - 4.0 Surround output to Front and Rear speakers
surround41:CARD=NVidia,DEV=0 - HDA NVidia, ALC883 Analog - 4.1 Surround output to Front, Rear and Subwoofer speakers
surround50:CARD=NVidia,DEV=0 - HDA NVidia, ALC883 Analog - 5.0 Surround output to Front, Center and Rear speakers
surround51:CARD=NVidia,DEV=0 - HDA NVidia, ALC883 Analog - 5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71:CARD=NVidia,DEV=0 - HDA NVidia, ALC883 Analog - 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
iec958:CARD=NVidia,DEV=0 - HDA NVidia, ALC883 Digital - IEC958 (S/PDIF) Digital Audio Output
dmix:CARD=NVidia,DEV=0 - HDA NVidia, ALC883 Analog - Direct sample mixing device
dmix:CARD=NVidia,DEV=1 - HDA NVidia, ALC883 Digital - Direct sample mixing device
dmix:CARD=NVidia,DEV=2 - HDA NVidia, ALC883 Alt Analog - Direct sample mixing device
dsnoop:CARD=NVidia,DEV=0 - HDA NVidia, ALC883 Analog - Direct sample snooping device
dsnoop:CARD=NVidia,DEV=1 - HDA NVidia, ALC883 Digital - Direct sample snooping device
dsnoop:CARD=NVidia,DEV=2 - HDA NVidia, ALC883 Alt Analog - Direct sample snooping device
hw:CARD=NVidia,DEV=0 - HDA NVidia, ALC883 Analog - Direct hardware device without any conversions
hw:CARD=NVidia,DEV=1 - HDA NVidia, ALC883 Digital - Direct hardware device without any conversions
hw:CARD=NVidia,DEV=2 - HDA NVidia, ALC883 Alt Analog - Direct hardware device without any conversions
plughw:CARD=NVidia,DEV=0 - HDA NVidia, ALC883 Analog - Hardware device with all software conversions
plughw:CARD=NVidia,DEV=1 - HDA NVidia, ALC883 Digital - Hardware device with all software conversions
plughw:CARD=NVidia,DEV=2 - HDA NVidia, ALC883 Alt Analog - Hardware device with all software conversions


By the way: The package "squeezelite-pa" gives the same overall behaviour, while the error messages are slightly different.

In the end, I get the impression, that the daemon may be seeing some different pulseaudio environment than a regular user?
As I installed the packages from the repos, no dedicated user has been created. Could that maybe solve the issue and what would I have to do to run the service as a dedicated user (editing daemon start/stop scripts?)? Any other ideas?

Bye & Thanks for reading...
W69

mongrel
2018-03-21, 01:19
I'd recommend purging the Debian packages and using one of the pre-built Linux binaries from the Sourceforge (https://sourceforge.net/projects/lmsclients/files/squeezelite/linux/) repo. The Jessie package version is very old and missing a lot of refinement.

Personally, I only run squeezelite on demand, so I have the squeezelite binary in ~/bin and a launcher for '~/bin/squeezelite -n PlayerName'. To stop squeezelite, I have another launcher for 'killall squeezelite'. My use case is for a single-user machine, so it works fine for me. You could start squeezelite on log-in by putting it in the autostart list (however it's done in your desktop environment), with a start delay if you need to make sure that the network is up.

ralphy
2018-03-21, 04:54
I have native pulseaudio squeezelite builds available for Debian 7, 8 and 9 on the sourceforge site.

I've been using it for about the last year and it works very well.

$ squeezelite -l
Output devices:
0 - Built-in Audio Analog Stereo [PulseAudio]

W69
2018-03-21, 06:11
Hi all,

thanks for your answers.

After some a little investigation and thinking I guess I know the root of the problem. I have some ideas, but so far I don't know what the BEST solution would be.

The problem is PulseAudio (PA).
PA can either run as a systemwide service (not recommended by the developers due to severe security concerns) or as a service that is run per user (more precise: per session). The last method is standard.

Squeezelite (SL) however will be run as a systemwide daemon on startup per default.

This obviously cannot work.

Possible solutions:
1. Run PA as a systemwide daemon to provide its service to any other application including SL (run as a systemwide daemon as well). Well, people that run Debian usually use Debian as they tend to rather be on the safe and stable side. So this option is highly questionable!

2. Run PA as usual and run SL (daemonized) per session. Doing so would ensure that SL sees the PA envionment as any other application (of that session) does. Efforts should be quite low: disable the systemwide SL daemon and adding SL to something like .sessionrc (depends on the system). The only drawback I see at the moment, is that a user has to be logged in and only this user has sound (with SL as well as with any other application).

3. Get rid of PA and try to configure everything without it. Although this approach appears rather appealing to me - mostly as I regard it being somewhat "clean" - it would imply to divert from most distributions' standards... which might not end up "clean" at all and result in a real admins nightmare.


As my intention is to centralize my music library in something like a NAS/LMS combination, I think I need to play music on the computers (other clients/players remain out of consideration for now) from that storage (NAS) as well. Using the same method of playing music (using LMS) to me seems to be just consequent. Well, as the normal use case of the desktop clients is clearly "single user", I don't see any real drawbacks of option 2 by now.

Personally, I'd like to discard option 1 for the reasons given above.

Option 3 has another drawback not yet mentioned. Some software seems to strictly depend on PA... take Skype for example. Not that I'd like that - but it's used in the family. As I do not indent to have several different setups, discarding PA also seems not to be an option.

Well... is there anything to say against option 2 that I missed?

Thanks for reading!
W69

W69
2018-03-21, 11:39
Hi al,,


I have native pulseaudio squeezelite builds available for Debian 7, 8 and 9 on the sourceforge site.
I'm going to need builds for x64 and RaspberryPis...

For the x64 machines and with PulseAudio, should I use
squeezelite-1.8.7-1052-debian8-x86_64.tar.gz
or
squeezelite-pulse-1.8.7-1052-debian8-x86_64.tar.gz
?

I ask, because I didn't notice any difference in behaviour, when installing squeezelite or squeezelite-pa from the standard Debian repos...

For the RaspberryPis (one is a RPi3, the other one a RPiZeroW), which one of these should I use:
squeezelite-1.8.7.1052-armel.tar.gz
squeezelite-1.8.7.1052-armv6hf.tar.gz
?

Thanks again
W69

ralphy
2018-03-22, 04:27
Hi al,,


I'm going to need builds for x64 and RaspberryPis...

For the x64 machines and with PulseAudio, should I use
squeezelite-1.8.7-1052-debian8-x86_64.tar.gz
or
squeezelite-pulse-1.8.7-1052-debian8-x86_64.tar.gz
?

I ask, because I didn't notice any difference in behaviour, when installing squeezelite or squeezelite-pa from the standard Debian repos...

For the RaspberryPis (one is a RPi3, the other one a RPiZeroW), which one of these should I use:
squeezelite-1.8.7.1052-armel.tar.gz
squeezelite-1.8.7.1052-armv6hf.tar.gz
?

Thanks again
W69

The squeezelite-pa binaries do NOT include the pulseaudio portaudio library driver only ALSA and OSS.

For pulseaudio you must use one of the squeezelite-pulse-*tar.gz files.

You can use either the armel or armv6hf files for the RPi3 or 0, however the armv6hf is the build meant for those boards.

No dice on a pulseaudio squeezelite build for RPis. The pulseaudio portaudio library driver just hangs when you start squeezelite.

W69
2018-03-22, 12:10
Hi Ralphy,

thanks for your answer.

So I will try the pulse_x86_64 versions for the desktops and armv6hf for the Raspis.
For the latter however, I still have to get these DACs and set everything up.
So I didn't know about PulseAudio for the Raspis... if it's not working/not there/... well that's fine for me.
Is there a special distro to be used for a Raspberry Pi Zero W + pHAT DAC + squeezelite? Picoreplayer perhaps?

Thanks again, now I'll give the binaries a try...
W69



EDIT:
The binaries are working nicely!

To start on login (more precise: on gdm login):
~/.config/autostart/start_squeezelite_userdaemon.desktop

[Desktop Entry]
Name="Autostart SqueezeLite Daemon"
GenericName="Autostart squeezelite daemon"
Comment="Autostart SqueezeLite Daemon per user session"
Exec=/usr/local/bin/squeezelite-pulse -n name -z
Terminal=false
Type=Application
NoDisplay=true

And to stop on logout (because you would end up with multiple instances if you logged in an out with different users...) we need 2 files:
/etc/gdm3/PostSession/Default

#!/bin/sh

logoutscript="$HOME/.gdmlogout"
if [ -x "$logoutscript" ] ; then
su $USER - "$logoutscript"
fi

exit 0

~/.gdmlogout (executable!)

#!/bin/bash

killall squeezelite-pulse

exit 0

This works so far. Some strange behaviour though:
1. Login. Start music via webinterface. Music is playing.
2. Logout, not stopping the music prior to logout! Music stops as squeezelite is killed.
3. Login again. After some 5-10 seconds, the music magicially starts again... sometimes the song starts from the beginning, sometimes where it was when logged out before.

Why is that? I've seen the players settings (section "Audio") and specifically the start/stop behaviour options in the webinterface. Whatever I set there... doesn't have any effect.
My thought was that killing squeezelite would look like "Power Off" for the server... obviously that's not the case?

If I run the standalone binary (not installing it via the systems package management)... does it look in /etc/default/squeezelite for settings? Would the option SL_AUTO_PLAY=false in there solve the issue? Or can I pass that option via the command line as well?

Cheers!
W69

ralphy
2018-03-23, 04:22
Thanks for the autostart desktop scripts.

I would recommend picoreplayer for the rpi0w and squeezelite comes installed.

There's an LMS per player audio setting called Power On Resume to change the behaviour to remain paused on power on but the default is to continue playing, it's not squeezelite specific.

W69
2018-03-24, 05:01
Hi Ralphy and all,


There's an LMS per player audio setting called Power On Resume to change the behaviour to remain paused on power on but the default is to continue playing, it's not squeezelite specific.
Hm, how to access that setting? Is it one of these:
24776
?

If yes, then which one would I chose to achieve what I intend? Where's the difference between
1. Pause at power off/Remain paused at power on
2. Stop at power off/Remain stopped at power on
?

Are these settings known to work properly with squeezelite clients?
I ask, because I didn't manage to achieve what I intend with these settings yet...






Thanks for the autostart desktop scripts.
I refined them in order to solve the autoplay issue as described above and to centralize everything. This should faciliate porting the scripts to another machine as well...


I decided to put the following in /usr/local/bin

the binary "squeezelite-pulse"
a script called "squeezelite-start-player-quiet.sh"
a script called "squeezelite-stop-player.sh"

modified /etc/gdm3/PostSession/Default as below
Put .gdmlogout in each individual home directory...
Put ~/.config/autostart/start_squeezelite_userdaemon.desktop




Explanation:

The autostart script in each users home directory (4) triggers the squeezelite-start-player-quiet.sh script (1b), which is available systemwide.
The squeezelite-start-player-quiet.sh (1b) starts squeezelite (1a) in daemon mode, waits 1 second, then sends the command to stop playback to the server (to prevent autoplay!).
On logout, /etc/gdm3/PostSession/Default (2) looks for an executable ~/.gdmlogout script (3) and if existing it will be executed. This systemwide setting should not hurt any user.
The ~/.gdmlogout script (3) triggers the "squeezelite-stop-player.sh" (1c) script but could be used for other stuff as well.
The "squeezelite-stop-player.sh" (1c) script simply sends another stop command to the server, then kills squeezelite.



And these are the files as described above:

squeezelite-start-player-quiet.sh (should be executable)

#!/bin/bash
LMS_NAME="servername.local"
LMS_PORT="9090"
SL_NAME=$(echo "$HOSTNAME")

/usr/local/bin/squeezelite-pulse -n $SL_NAME -z
wait 1
printf "$SL_NAME stop\nexit\n" | nc $LMS_NAME $LMS_PORT > /dev/null

exit 0


squeezelite-stop-player.sh (should be executable)

#!/bin/bash
LMS_NAME="servername.local"
LMS_PORT="9090"
SL_NAME=$(echo "$HOSTNAME")

printf "$SL_NAME stop\nexit\n" | nc $LMS_NAME $LMS_PORT > /dev/null
wait 1
killall squeezelite-pulse

exit 0


~/.gdmlogout (needs to be set as executable)

#!/bin/bash

/usr/local/bin/squeezelite-stop-player.sh

exit 0


/etc/gdm3/PostSession/Default (should be executable)

#!/bin/sh

logoutscript="$HOME/.gdmlogout"
if [ -x "$logoutscript" ] ; then
su $USER - "$logoutscript"
fi

exit 0


start_squeezelite_userdaemon.desktop (needs to be set as executable)

[Desktop Entry]
Name="Autostart SqueezeLite Daemon"
GenericName="Autostart squeezelite daemon"
Comment="Autostart SqueezeLite Daemon per user session"
Exec=/usr/local/bin/squeezelite-start-player-quiet.sh
Terminal=false
Type=Application
NoDisplay=true


Maybe this helps others as well...

Cheers
W69

W69
2018-03-25, 02:25
Hi DJanGo,

thanks for your answer.


since you find exact the phrase in lms ralphy told you about - there is a 100% yes
You may have noticed - or not - that I'm not a native English speaker. I just wanted to make sure I found the correct setting Ralphy mentioned.
Initially I suspected these settings to be those he mentioned, but I switched to English locale and posted the screenshot just to make sure.
Thanks for your confirmation that I found the correct setting.

Now, I'm using the binaries of squeezelite as provided from Ralphy and as suggested in this thread.
I read from your posting, that these should support the correct behaviour of that setting. Thanks for your confirmation of that as well.

Now just imagine my scripts without the stop commands... this would end up in squeezelite producing NOT the expected behaviour.
Whatever option I chose - squeezelite would automatically start playing again, when started with an autostart script and killed on logout.
As I wrote: That (unexpected behaviour) has been the reason I asked to confirm whether I found the correct settings.
You say these are the settings and they should work, I can tell you they don't.
The only reason I can imagine is that a kill is not recognized as a "Power off".


Cheers
W69

W69
2018-03-25, 02:52
Hi DJanGo,


using one Variable with the exact value of an already existing variable istnt that smart as it looks.
eg.


printf "$$HOSTNAME stop\nexit\n" | nc $LMS_NAME $LMS_PORT > /dev/null
piping the printf to > /dev/null is the same - not a good idea.

First, yes it may be smart.
What if I wanted to set $LMS_NAME differently per user? Or set it via the -N option according to a file's content (that may live in the users' homedir)?
What if I wanted to expand the script to do other stuff as well?
In my script I would have to change only one assignment and that's it.
To some it might seem like a waste of memory, to me it's just better style to define an extra variable to contain what it says to contain - whatever that may be.

Second, I don't pipe printf to /dev/null. Printf is piped to nc ... whose output is redirected to /dev/null, because I don't need it.
I couldn't imagine for what? Debugging maybe? If I intended to do that, then I would...


Just "stop" a player thats maybe online or not - maybe stopped or not - is a even better:mad: idea.
I suppose you're being sarcastic? Please keep in mind that this may not be a good idea, when communicating with non native speakers.
If you think, that's a bad idea, would you mind telling me why? The scripts in fact do work as expected.


You should use something and only that something - not something here (autostartscript) and some autoplaysettings.
Yes, I totally agree with you that preferably one should use only ONE kind of setting that's intended to do something.
As it doesn't work as expected, I tried to find another solution that obviously works.
I'm sure you can tell me, where I failed to get it working the "normal" way.


Oh, by the way... I think I didn't mention where I found the method to printf cli commands and send them to LMS via nc.
I had a look at the daemon-start-stop scripts that are supplied with the debian distro package (outdated or not - doesn't matter, this has been approved to be correct at some time).
In that script, the setting $SL_AUTO_PLAY is evaluated. This setting can be made in /etc/default/squeezelite as central configuration file for squeezelite. If $SL_AUTO_PLAY is true, then a "play" command is sent to LMS. So in that official package, they're doing exactly the same as I do (just the other way round) and use a method (cli commands via nc), where another method (settings in LMS) should be used according to you. Why is that?

Cheers
W69

ralphy
2018-03-25, 04:59
As long as you don't kill -9 the squeezelite program the signal handler sends the slimprotocol STOP command (https://github.com/ralph-irving/squeezelite/blob/master/main.c#L233) to the server before it quits.

I should mention that as soon as you run more than one instance of squeezelite on the same system you MUST add the -m parameter with a unique MAC address or set the UTMAC environment variable and squeezelite will use that MAC to annouce itself to LMS. This again must be per user not global.

Two or more players using the same MAC causes LMS to be unable to control any of the players with the same MAC reliably.