ralph-irving / squeezelite Goto Github PK

Hi,
The vast majority of my music library is encoded as ALAC. About 80% of it plays fine in squeezelite, however the other 20% experiences serious issues. The problems manifest in a few ways:

1. Track plays well all the way through, but stalls at the end. Will not continue on to the next track
2. Track will not start. Player appears to be trying to play the file, but progress bar does not move and no audio is heard. Playback stalls until another track is selected.
3. Track appears to be playing but no audio is heard.

Sometimes the stalled or silent tracks will work after skipping forward and then back to the problem track to "try again".

To me the issue seems to be that squeezelite is having trouble decoding tracks encoded by a particular tool. Not sure which one it would be though. I've used several over the years including iTunes, XLD, ffmpeg, foobar2000 and JRiver Media Centre.

All my music plays fine on other players including iPhone, Kodi, iTunes, JRiver & iPeng.

I'm using squeezelite 1.8.6-998 on RPi 2 running Libreelec 8.1.1 but I have the same issues on my MacBook Pro with Squeezelite v1.8.6-945

Once these errors occur, the squeezelite log is filled with errors and can very quickly grow in size to several hundred Mb.

The session for the log below went something like:

1. Squeezelite start up
2. Play a few songs uneventfully
3. Play Track 1
4. Track 1 plays well but stalls at end.
5. Skip to Track 2
6. Track 2 appears to play but no music heard.
7. Some skipping back and forth
8. Track 2 plays and music heard

squeezelite log
Track 1
Track 2

Hi,
Is it possible to point the -V command to a specific device?

In a setup with RPI > piCore > USB dac (Dragonfly (with ESS9023)), Card0 (internal RPI audio) and card1 (DF) share the name: 'PCM' under the Alsa volume slider. When adding '-V PCM', the Alsa volume of Card0 can be controlled. I should want to control Card1, DF. Tried to disable internal RPI audio. DF is then Card0, but the Alsa volume reset's to zero when moving remote volume +/-.

Great work and kind regards,
Hans

There are currently no releases tagged which makes it difficult to fetch a particular release for packaging.

If I disconnect my USB DAC while LMS is playing, LMS could no longer reestablish any USB connection until I reboot my Pi 3. Just re-plugging the USB DAC back won't reestablish sound.

I tried to restart Squeezelite and LMS service but none of them helps. Rebooting the device is the only way help LMS establish USB connection.

I got the following error (looping) after unplug the USB DAC.

[22:11:44.506807] output_thread:776 pcm wait error: Input/output error
[22:11:44.506898] output_thread:763 start error: File descriptor in bad state
[22:11:44.516943] output_thread:763 start error: File descriptor in bad state
[22:11:44.526985] output_thread:763 start error: File descriptor in bad state
[22:11:44.537027] output_thread:763 start error: File descriptor in bad state

The DAC I'm using is RME ADI-2 DAC.

Orginally repotted at https://forums.slimdevices.com/showthread.php?109934-LMS-could-not-reestablish-any-USB-connection-after-USB-Dac-is-disconnected

Is there a reason why ffmpeg isn't added to all formats as it can handle (granted that support is included in ffmpeg) ie flac, aac, mp3 etc or am I reading the code wrong? That would reduce the amount of dependencies considerably.
https://github.com/ralph-irving/squeezelite/blob/master/decode.c#L162

Unsure whether this should be handled by squeezlite or jivelite, but..

I am building a raspberry pi, with touch screen for my kids and would like to add support for local media aka CD's to be played back from the local CD-rom drive.

Would that be feasible?

Hi Ralph,

I have squeezelite version v1.9.0-1098 installed using the sources on the Archlinux User Repository on a Raspberry Pi 2 (kernel 4.14.78-2).

I use the following startup in systemd:
ExecStart=/usr/bin/squeezelite -o hw:CARD=MYDAC,DEV=0 -C 2 -e dsd -a 499:::0 -d all=debug -f /tmp/squeezelite.log

After a while, which can be a couple of minutes or hours and while playing music, squeezelite terminates unexpectedly, see last part of the log file attached.

squeezelite.log

Hope you can help me out!

Thanks!
Hans.

I'm experiencing a problem with some m4a files in squeezelite on Linux (ARM and x86): Playback of these files fails with the following output on decode=debug:

[18:07:33.303794] decode_flush:229 decode flush
[18:07:33.420717] codec_open:257 codec open: 'a'
[18:07:33.420766] faad_open:541 opening mp4 stream
[18:07:33.959528] read_mp4_header:295 type: ftyp len: 24 consume: 24
[18:07:33.959588] read_mp4_header:236 type: mdat len: 7256342 pos: 32
[18:07:33.959606] faad_decode:373 samplerate: 44100 channels: 2
[18:07:33.959627] faad_decode:378 setting track_start
[18:07:33.959668] faad_decode:415 error: 32 Bitstream value not allowed by specification
[18:07:33.959689] faad_decode:454 unable to decode further
[18:07:33.959710] decode_thread:100 decode error
[18:07:34.060552] decode_flush:229 decode flush

Here's the mediainfo output for one of the files in question:

General
Complete name                            : Jayme Stone/Jayme Stone's Lomax Project/01 Lazy John.m4a
Format                                   : MPEG-4
Format profile                           : Base Media / Version 1
Codec ID                                 : mp41 (mp41/isom)
File size                                : 7.22 MiB
Duration                                 : 3 min 1 s
Overall bit rate mode                    : Constant
Overall bit rate                         : 334 kb/s
Album                                    : Jayme Stone's Lomax Project
Track name                               : Lazy John
Track name/Position                      : 1
Performer                                : Jayme Stone
Encoded date                             : UTC 2014-12-24 16:16:01
Tagged date                              : UTC 2015-09-27 19:27:04
Cover                                    : Yes

Audio
ID                                       : 1
Format                                   : AAC LC
Format/Info                              : Advanced Audio Codec Low Complexity
Codec ID                                 : mp4a-40-2
Duration                                 : 3 min 1 s
Bit rate mode                            : Constant
Bit rate                                 : 320 kb/s
Channel(s)                               : 2 channels
Channel layout                           : L R
Sampling rate                            : 44.1 kHz
Frame rate                               : 43.066 FPS (1024 SPF)
Compression mode                         : Lossy
Stream size                              : 6.92 MiB (96%)
Language                                 : English
Encoded date                             : UTC 2014-12-24 16:16:01
Tagged date                              : UTC 2015-09-27 19:27:04

Linux distributions are Raspbian stretch on ARM and Debian stretch on x86. On the latter, I have tried a self-compiled version of squeezelite with identical results to the packaged version.

The faad binary linked against the same libfaad is able to decode the file without issues.

I can provide one of the affected files on request.

Thanks very much in advance for any help!

I was seeing some issues with my modified squeezelite version for AirPlay bridge and fading + replaygain (maybe). I did the same correction you did in commit #724 a while ago, for the same reasons (compiler warning) but never reverted it. It seems to me that the original test is wrong

if (!ctx->output.fade == FADE_ACTIVE || !ctx->output.fade_mode == FADE_CROSSFADE)

This cannot be right. fade is an enum so !fade will never be FADE_ACTIVE (==2). this part of the expression is always false. It's ORed with !fade_mode which will only equal FADE_CROSSFADE (==1) if fade_mode is FADE_NONE. So replay gain is set to new one only when fade_mode it set to NONE, which is not desired for IN, OUT and INOUT. So I don't understand how the original version could work

Isn't what is trying to be done the following?

if (ctx->output.fase == FADE_INACTIVE || ctx->output.fade_mode != FADE_CROSSFADE)

In other words, change reply gain at track start when there is no fading or it is cross_fading? The current track shall be faded out with it's own (old) gain, the new track shall be faded in with its own (new) gain.
But with cross-fading, as said below in the code, the current_gain shall be retained to be applied on the old track piece while new gain is apply on the new track piece and the mix happens

 } else if (ctx->output.fade_mode == FADE_CROSSFADE) {		
      LOG_INFO("[%p]: crossfade complete", ctx);
  if (_buf_used(ctx->outputbuf) >= dur_f * BYTES_PER_FRAME) {
	_buf_inc_readp(ctx->outputbuf, dur_f * BYTES_PER_FRAME);
	LOG_INFO("[%p]: skipped crossfaded start", ctx);
 } else {
	LOG_WARN("[%p]: unable to skip crossfaded start", ctx);
}
ctx->output.fade = FADE_INACTIVE;
ctx->output.current_replay_gain = ctx->output.next_replay_gain;`

Why did you revert to the old test then? I did test with the "corrected test" and fade-in, out and cross work as expected with expected replay gains

Hi,
Having installed your own build of squeezelite from lms_clients (for which many thanks) I thought I'd had a go at compiling one myself with all the bells and whistles. All went fine except for IR. I have installed liblirc-dev 0.10.0-2, and my build line is:

OPTS="-DFFMPEG -DRESAMPLE -DVISEXPORT -DIR -DGPIO -DDSD -DLINKALL" make -B

The errors I get are all for LOG_DEBUG as below:

In file included from /usr/include/syslog.h:1:0,
from /usr/include/lirc/lirc_client.h:119,
from ir.c:28:
ir.c: In function ‘ir_key_map’:
ir.c:119:4: error: called object is not a function or function pointer
LOG_DEBUG("repeat suppressed");
^
ir.c: In function ‘ir_thread’:
ir.c:143:6: error: called object is not a function or function pointer
LOG_DEBUG("ir cmd: %s -> %x", c, ir_code);
^
ir.c:157:5: error: called object is not a function or function pointer
LOG_DEBUG("ir lirc: %s [%s] -> %x", b, r, ir_code);
^
ir.c:164:5: error: called object is not a function or function pointer
LOG_DEBUG("code dropped");
^
Makefile:87: recipe for target 'ir.o' failed
make: *** [ir.o] Error 1

After many experiments and searching, I found I could overcome this by changing ir.c to include squeezelite.h after lirc/lirc)client.h, as follows:

#if IR
#include <lirc/lirc_client.h>
#include "squeezelite.h"

I then get warnings as follows:

_In file included from ir.c:29:0:
squeezelite.h:397:0: warning: "LOG_INFO" redefined
#define LOG_INFO(fmt, ...) if (loglevel >= lINFO) logprint("%s %s:%d " fmt "\n", logtime(), FUNCTION, LINE, ##VA_ARGS)

In file included from /usr/include/syslog.h:1:0,
from /usr/include/lirc/lirc_client.h:119,
from ir.c:28:
/usr/include/x86_64-linux-gnu/sys/syslog.h:57:0: note: this is the location of the previous definition
#define LOG_INFO 6 /* informational */

In file included from ir.c:29:0:
squeezelite.h:398:0: warning: "LOG_DEBUG" redefined
#define LOG_DEBUG(fmt, ...) if (loglevel >= lDEBUG) logprint("%s %s:%d " fmt "\n", logtime(), FUNCTION, LINE, ##VA_ARGS)

In file included from /usr/include/syslog.h:1:0,
from /usr/include/lirc/lirc_client.h:119,
from ir.c:28:
/usr/include/x86_64-linux-gnu/sys/syslog.h:58:0: note: this is the location of the previous definition
#define LOG_DEBUG 7 /* debug-level messages */_

I assume that the version of liblirc on ubuntu 17.10, or the presence of some other library on my system, means that in your version of ir.c the definition of LOG_DEBUG from squeezelite.h is overridden by something in lirc/lirc_client.h.

I don't actually have IR on my system, so this is not a problem for me, but it might be for others in due course.

Hello,

Here is a part of the log on Ubuntu 16.04:

/usr/bin/squeezelite -n rockeurs-desktop -o front:CARD=A20,DEV=0 -d all=debug -f /var/log/squeezelite.log
[19:32:29.937896] stream_init:290 init stream
[19:32:29.938459] stream_init:291 streambuf size: 2097152
[19:32:29.941466] output_init_alsa:817 init output
[19:32:29.941643] output_init_alsa:846 requested alsa_buffer: 40 alsa_period: 4 format: any mmap: 1
[19:32:29.941670] output_init_common:346 outputbuf size: 3528000
[19:32:29.941803] output_init_common:370 idle timeout: 0
[19:32:29.968946] ALSA snd_pcm_hw_open:1590 open '/dev/snd/pcmC1D0p' failed (-16)
[19:32:29.969270] test_open:294 playback open error: Device or resource busy
[19:32:29.969319] output_init_common:381 unable to open output device

It looks like the device is already used by something at startup (maybe pulseaudio).

Is there a way to avoid this problem ?

Hi

I get the following error when trying to compile on OS X:

$ make all
cc -Wall -fPIC -O2   main.c -c -o main.o
cc -Wall -fPIC -O2   slimproto.c -c -o slimproto.o
slimproto.c:672:57: warning: use of logical '||' with constant operand [-Wconstant-logical-operand]
                        if (_start_output && (output.state == OUTPUT_STOPPED || OUTPUT_OFF)) {
                                                                             ^  ~~~~~~~~~~
slimproto.c:672:57: note: use '|' for a bitwise operation
                        if (_start_output && (output.state == OUTPUT_STOPPED || OUTPUT_OFF)) {
                                                                             ^~
                                                                             |
1 warning generated.
cc -Wall -fPIC -O2   buffer.c -c -o buffer.o
cc -Wall -fPIC -O2   stream.c -c -o stream.o
cc -Wall -fPIC -O2   utils.c -c -o utils.o
cc -Wall -fPIC -O2   output.c -c -o output.o
output.c:154:22: warning: comparison of constant 'FADE_ACTIVE' (2) with boolean expression is always false [-Wtautological-constant-out-of-range-compare]
                                if (!output.fade == FADE_ACTIVE || !output.fade_mode == FADE_CROSSFADE) {
                                    ~~~~~~~~~~~~ ^  ~~~~~~~~~~~
1 warning generated.
cc -Wall -fPIC -O2   output_alsa.c -c -o output_alsa.o
cc -Wall -fPIC -O2   output_pa.c -c -o output_pa.o
cc -Wall -fPIC -O2   output_stdout.c -c -o output_stdout.o
cc -Wall -fPIC -O2   output_pack.c -c -o output_pack.o
cc -Wall -fPIC -O2   decode.c -c -o decode.o
cc -Wall -fPIC -O2   flac.c -c -o flac.o
cc -Wall -fPIC -O2   pcm.c -c -o pcm.o
cc -Wall -fPIC -O2   mad.c -c -o mad.o
cc -Wall -fPIC -O2   vorbis.c -c -o vorbis.o
cc -Wall -fPIC -O2   faad.c -c -o faad.o
cc -Wall -fPIC -O2   mpg.c -c -o mpg.o
cc main.o slimproto.o buffer.o stream.o utils.o output.o output_alsa.o output_pa.o output_stdout.o output_pack.o decode.o flac.o pcm.o mad.o vorbis.o faad.o mpg.o -lasound -lpthread -lm -lrt -o squeezelite
ld: library not found for -lasound
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [squeezelite] Error 1

I can't find any asound on homebrew - how can I compile squeezelite on os-x?

Thanks,

Rainer

Hi!

Using the -G to trigger a relay with the GPIO in the raspberry Pi 3+ has some strange behaviour when -C is set.

On my system -G 24:H -C 5 will trigger the relay everytime a pause, fast forward, backward tracking, or next song is selected on LMS, iPeng or Spotify through spotty.

Removing -C 5 will bring back the expected behaviour.

Thanks for his amazing project!!

Hello, I am the developer of the Aroio streaming OS. It's free as well as available in commercial products from Abacus Electronics in Germany. It supports multiple players and soundcards and has brutefir for convolution purposes.
I am currently rebuilding the entire system using buildroot. It can be found here: https://github.com/unicap/aroio-ng

Of course we are also using squeezelite! :) Sadly we are facing problems when outputting to jackd via alsa-jack-bridge. Outputting to alsa directly works fine. The jack-bridge is working fine with the three other players, as well as using aplay directly from commandline, therefor I consider the alsa/jack-setup to be very stable.

jackd is set to a fixed sampling-frequency and the alsa-jack-bridge defined in asound.conf is taking care of resampling, when necessary.

Now when running jackd with 44.1 or 48 kHz playing back tracks with squeezelite works fine up until 96 kHz. Above that comes either stuttering or "File descriptor is in bad state".

When running jackd at 96 kHz or higher playing back tracks works fine up until 88 kHz.

I did try every possible combination of buffers that squeezelite allows but without success. Maybe you can help. Thx in advance!

Hi,

I use the mixcloud plugin with LMS, and squeezelite to play. On all the streams I've tried, the audio works happily for 20 minutes or so, the stops. Running squeezelite in debug, I see the following at the time the audio stops:

...
[11:34:45.287290] _output_frames:273 wrote 441 frames                 
[11:34:45.297055] _output_frames:113 avail: 441 frames: 435315 silence: 0
[11:34:45.297226] _output_frames:273 wrote 441 frames                 
[11:34:45.304624] decode_thread:74 streambuf bytes: 163 outputbuf space: 49007
[11:34:45.305065] faad_decode:414 error: 15 Array index out of range  
[11:34:45.305199] faad_decode:453 unable to decode further
[11:34:45.305279] decode_thread:99 decode error                       
[11:34:45.305440] sendSTAT:142 ms_played: 511570 (frames_played: 22561389 device_frames: 1545)
[11:34:45.305557] sendSTAT:171 STAT: STMn                             
[11:34:45.305633] sendSTAT:176 received bytesL: 4887988 streambuf: 163 outputbuf: 3478992 calc elapsed: 511570 real elapsed: 515967
[11:34:45.307205] _output_frames:113 avail: 441 frames: 434874 silence: 0
[11:34:45.307387] _output_frames:273 wrote 441 frames
[11:34:45.317158] _output_frames:113 avail: 441 frames: 434433 silence: 0
...

Any thoughts?

best regards,
Richard

Moving a wandboard to Debian 9 / 4.13.x and encountering:

[11:03:13.957533] ALSA snd_pcm_hw_start:632 SNDRV_PCM_IOCTL_START failed (-77) [11:03:13.957682] output_thread:701 start error: File descriptor in bad state ...

wondering if this is a known issue.

I would like to set up shairport-sync to end an active squeezelite session. Can you add hooks to make that possible?

Hi Ralph - I'm wondering if there is not an issue in output.c, line 287 when calculating fade_start in case of fade-out

if (output.fade_mode == FADE_INOUT) { bytes /= 2; }

As outputbuf is consumed by BYTES_PER_FRAME increments, if bytes/2 does not align with a frame, then fade_start is never reached

output.fade_start = outputbuf->writep - bytes;

At least I had the problem in my modified version

Hey,

I'm using squeezelite on three raspberry pis to build a multiroom audio system with squeezeserver controlling them. If I synchronise players I've run into the problem, that some frames are skipped frequently which leads to some crackle / distorted sound. Log output shows the following:

[12:12:15.997528] _output_frames:67 skip 529 of 529 frames
[12:12:40.014648] _output_frames:67 skip 441 of 441 frames
[12:12:51.001910] _output_frames:67 skip 573 of 573 frames
[12:13:04.009516] _output_frames:67 skip 441 of 441 frames
[12:13:09.003884] _output_frames:67 skip 485 of 485 frames
[12:13:17.017390] _output_frames:67 skip 529 of 529 frames
[12:13:35.018464] _output_frames:67 skip 705 of 705 frames
[12:13:44.008478] _output_frames:67 skip 441 of 441 frames
[12:13:54.019698] _output_frames:67 skip 441 of 441 frames
[12:14:01.011224] _output_frames:67 skip 529 of 529 frames
[12:14:10.998662] _output_frames:67 skip 529 of 529 frames
[12:14:25.005791] _output_frames:67 skip 573 of 573 frames
[12:14:36.015526] _output_frames:67 skip 529 of 529 frames
[12:14:42.008546] _output_frames:67 skip 441 of 441 frames
[12:14:49.023294] _output_frames:67 skip 529 of 529 frames
[12:14:55.015751] _output_frames:67 skip 617 of 617 frames
[12:15:03.006710] _output_frames:67 skip 617 of 617 frames

I already tried to modify the alsa parameter, but I can't find the right ones...
Here is a sample call of squeezelite:
squeezelite-armv6hf -s 192.168.178.2 -o plughw:CARD=ALSA,DEV=0 -n LivingRoom -d all=info -a 2000:8:16:1 -r 48000 -m 00:00:00:00:01:01

What causes these frame skips? How can I avoid them?

By the way: I'm using usb soundcards, not the raspberry pis internal sound output.

Thanks in advance!
Niklas

hi,
ive been running one of the latest squeezelite builds (v1.8.6-986) with LMS which is current as well (7.9.1 from August) . Have been squeezelite and LMS user for over 4 years ...
Have not been using 'sync' with 2 players for a long time (2+ years) when it worked perfectly (all my players are squeezelite).
Currently, i have 3 players (arm endpoints , odroidc2, odroidxu4 and nanopineo). Tried squeezelite personally compiled as well as those that come with distributions ... net is I can not get synchronising to work well and one or more time during 3 mins song i hear how some ammount is skipped and message logged is:

11:59:49.710556] _output_frames:70 skip 22623 of 22623 frames

Logging is 'all=info' and above is the only message i get. I am trying to synchrhonise 2 out of the 3 players (as i have only 2 USB DACs) at any given point of time and behaviour is the same in all combinations.

Network is all devices are wired (1Gbps) ethernet ... LMS running on ubuntu 16.04.3 and players are running also ubuntu 16.04.3 and kernels (tried both mainline and legacy) are either 4.9 (odroid xu4) or 4.11 and 4.13 on odroidc2 and nanopineo respectively ... alos (3.x for all 3).

I am pretty sure there are no kernel issues - squeezelite works perfectly when not synced to other players ... no skips/bleeps nothing - perfect. Roon works great and there are no heard skips when i use roon (with Roon Bridge endpoints) ... so there must be something with the squeezelite or lms that is not ok or some setting that i should try to change.

BTW, i have tried in LMS settings to change 'sync. adjustment' from 10 to 100ms and it made no difference ...

help please !
thank you

Hey Ralph, I've forked squeezelite as well and built a rpm package for squeezelite as well.
It's here: https://github.com/fhuberts/squeezelite

I did way less adjustments than you but I'm interested in merging my changes into your repo since your repo is the basis for the Fedora package.

Basically, the things I added were files to just make it an app, so that regular desktop users can start and stop it.

Please let me know :-)

Hi,

I am the maintainer of the "Aroio" streamer from abacus-electronics. I ran into problems when trying to update some software packages:

After updating alsa from 1.1.6 to 1.1.7 (or 1.1.8 same behaviour) I am getting alsa_open:490 unable to set buffer time Invalid argument errors when going through an alsa-jack bridge, which has a plug plugin in the chain set in /etc/asound.conf. See below.

The bridge itself is working fine when I use it with aplay.
squeezelite is working fine when I take the plug plugin out of the bridge and play to the actual bridge using S32_LE.
Strangely, configuring the plug plugin to output to hw:0 insted of the jalsa-jack bridge works fine with squeezelite.

I cannot figure out, in which part of the chain the error is happening, but since aplay manages to come through, I guess it is related to the playing application, or can at least be taken care of there.

Below some more information. Please let me know, if there is anything else I can provide to help finding the issue.

Here is the relevant log: https://pastebin.com/ZH18iWVu
This is the bridge in asound.conf:

# jack output with conversions and multi-inputs
pcm.jack {
    type plug
    hint {
    description
    "Jack Audio Bridge"
    }
    slave.pcm "rawjack"
}

# jack output to jackmixer
pcm.rawjack {
    type jack
    playback_ports {
        0 jackmixer:in1_left
        1 jackmixer:in1_right
    }
    capture_ports {
        0 system:capture_1
        1 system:capture_2
    }
}

I need to use pulseaudio for the audio playback and have divided some of my channels into sinks. Now I need squeezelite to play to a specific sink. Is there any parameter I can use for this?

Or do you may know of a possibility to control playback to the right sink by editing the pulseaudio config?

Hi Ralph:

I am having horrible problems with Squeezelite (1.8.5-823) on an Odroid C2 with HiFi Shield+ running the DietPi distribution.

Generally, the sound problems start immediately with the second track (prior to that the sound is great! -- so that and other tests indicate the hardware is functioning properly). Where I play longform classical music, sometimes the bad sound seems to start after maybe 7 minutes or so (I think within the same track -- but I would need to go back and double check).

Audio file format does not matter. This happens with FLAC, OGG, MP3

I am invoking Squeezelite thusly:
/usr/bin/squeezelite -o hw:CARD=ODROIDDAC,DEV=0 -a 160:0:0:0 -n 'LR-DietPi-Squeezelite' -d all=debug -f /var/log/squeezelite.log

My problem almost certainly lies with "-a 160:0:0:0" -- I have tried simply "-a 80" and "-a 160" (i.e. presumably removing the other 3 parameters) which are discussed in various blogs as a "solution" to bad sound from Squeezelite. Unfortunately, that doesn't seem to help -- same poor sound.

A few minutes ago I enabled logging at debug level and this doesn't give me any immediately obvious information on how to fix things. I've attached it.

At (I think) [11:26:20.552030] a track ends, everything subsequent to that sounds horrible. This was a batch of MP3 files, but as discussed, the format does not seem to matter one iota (although the "quality" of the poor sound seems to be a bit different with FLAC).

I am outputting via HiFi Shield+ using RCA cables. I could (and will eventually) switch to TOSLINK (which might solve the problem in and of itself?), but would like to start by identifying whether the RCA connectors have a hardware fault . . .

Any possible help would be appreciated!

Log attached.
FBachofner.squeezelite.log.txt

Original plea for help (with possibly a bit more information) at DietPi: http://dietpi.com/phpbb/viewtopic.php?f=9&t=1825&p

One difference I've noticed between squeezelite and a real Squeezebox is when I sync another player mid song. With real Squeezeboxes, there is a slight glitch, and then the song continues. With squeezelite, however, the song restarts from the beginning.

I am using it with logitechmediaserver-7.9.0-0.88.20150815git1439462737

Any ideas?

@ralph-irving - I just added support for HTTPS streaming to LMS. Many stations are and will be moving to secured connections. Right now those streams are all transcoded on the server, as none of the players does support native HTTPS streaming. But you could change the game ;-)

LMS-Community/slimserver@aa99239

What you'd have to do is add "CanHTTPS=1" to the capabilities string in slimproto. And add SSL, of course :-).

I've noticed that Squeezelite (and pulse in particular) have trouble with 48KHz files (at least under Ubuntu 14.04). I can reliably cause it so I have to reset squeezelite and pulseaudio to get them to work again.

I seem to have fixed it by setting the LMS server to only give out 44.1KHz streams to Squeezelite.

Please let me know what additional debugging information you might need to help reproduce / diagnose this issue.

I use an external DAC via USB 2.0.

Let's say I'm playing Internet ratio station X. While it's playing I'm browsing and a chat request comes in. Normally this would cause a "beep" sound but Squeezelite holds the audio stream exclusively so at the time we don't hear it. No problem, but the beep gets queued for playback.

When I then change audio to station Y, the previously unplayed "beep" sneaks in, plays, and then Squeezelite doesn't regain control of the palyer and requires a restart.

When squeezelite is in the background, it keeps an audio channel open. It uses CPU time and keeps the CPU from going to sleep. It would be best if the audio channel were only opened when playback was needed.

Hi there,

I've been searching for a Squeezelite version for OS X and seemed to follow lots of old threads to this repo. Can you point me at any newer version that you know about if that's the case?

Secondly, there doesn't seem to be any build instructions in the repo so I tried 'make' from OS X and it falls over with a missing dependency on PortAudio. Should your Makefile not check that all required components are available and error to the user if they don't exist? Or perhaps you could just list in a README the packages you expect/require to be installed for the compilation to succeed?

Thanks.

Seems dsd.c only supports DoP which limits playback to DSD128.

ALSA already should support native DSD playback, so I'm wondering if you are working on this, or if I could try my hand at it.

If the latter, if you have any ideas for how to organize my changes, such as "add new native_dsd.c file" or something, I'm all eyes.

hi, just upgraded squeezelite to r999 ... previous one i was using (and went back to was 977).
single player connected to 7.9.1 LMS (no change there for a while) keeps producing error:
Version/release 977 does not have that issue. Not sure if it's linked with latest upgrade (timer related) or Openhub fix at 985 update.

20:12:18.263058] output_thread:701 start error: File descriptor in bad state
[20:12:18.273136] output_thread:701 start error: File descriptor in bad state
[20:12:18.283212] output_thread:701 start error: File descriptor in bad state
[20:12:18.293289] output_thread:701 start error: File descriptor in bad state
[20:12:18.303368] output_thread:701 start error: File descriptor in bad state
[20:12:18.313575] output_thread:701 start error: File descriptor in bad state
[20:12:18.323656] output_thread:701 start error: File descriptor in bad state
[20:12:18.333737] output_thread:701 start error: File descriptor in bad state
[20:12:18.343813] output_thread:701 start error: File descriptor in bad state
[20:12:18.353889] output_thread:701 start error: File descriptor in bad state
[20:12:18.363997] output_thread:701 start error: File descriptor in bad state
[20:12:18.374074] output_thread:701 start error: File descriptor in bad state
[20:12:18.384152] output_thread:701 start error: File descriptor in bad state
[20:12:18.394226] output_thread:701 start error: File descriptor in bad state

hi Ralph,
.798 is the last version that worked for me with ALSA unmuting and/or volume control.
I do have Benchmark DAC2 connected to Odroid-C2. Running Armbian. Though I have not checked it thin i have the same issue with Intel box that i used to use until 2 weeks ago.

with versions prior to and including 798:

`
zh@odroidc2:~/sl.7xx/squeezelite-1836154eb82bb0cf4310ec109be379ddb6900bcf $ sudo ./squeezelite -n odroidc2 -o hw:CARD=B20,DEV=0 -L

Volume controls for hw:CARD=B20,DEV=0
Benchmark DAC2 Clock Selector Playback Volu
Benchmark DAC2 Clock Selector Playback Volu,1`

from 799 onwards it prints (to the same command)
Volume controls for default
Maybe configuration needs to be done differently ?

thank you

Hi Ralph,

I'm looking for a way to provide a command line parameter that would allow the ALSA volume controls to be set to a percentage of what is shown in Squeezeserver/iPeng. The reason is that I have Squeezelite plugged in to a USB-DAC (Audiolab M-DAC) controlling the DAC hardware volume control via USB. The following is my runtime (with additional logic to pin squeezelite on to a dedicated core!!!):

/usr/bin/squeezelite -n remote -o hw:CARD=MDAC -s localhost -C 5 -r 96000 -V PCM -d all=info

This works great but I would like to be able to lock (attenuate) the maximum output to say 30% of the 65536 full gain output so as not to accidentally blow speakers by turning volume up too high, or accidently setting 'Output level is Fixed at 100% in Squeezeserver. It would also allow the full volume range show in iPeng/Squeezeserver to control the restricted hardward volume range. Ideally I'd be able to achieve this without resorting to ALSA plugins (eg. softvol).

I'm keen to seek your advice in terms of whether this requires relatively simple changes to main.c and output_alsa.c and the associated headers. I'm new to C but happy to dig in to look at what code changes would be required. The crux of the change as I see it would involve the following change to output_alsa.c (with other minor changes to read the command-line parameters etc:

void set_volume(unsigned left, unsigned right) {
	float ldB, rdB;

	if (!alsa.volume_mixer_name) {
		LOG_DEBUG("setting internal gain left: %u right: %u", left, right);
		LOCK;
		output.gainL = left * alsa.volume_scaling / 100;
		output.gainR = right * alsa.volume_scaling / 100;
		UNLOCK;
		return;
	} else {
		LOCK;
		output.gainL = FIXED_ONE * alsa.volume_scaling / 100;
		output.gainR = FIXED_ONE * alsa.volume_scaling / 100;
		UNLOCK;
	}

	// convert 16.16 fixed point to dB
	ldB = 20 * log10( left * alsa.volume_scaling / 6553600.0F );
	rdB = 20 * log10( right * alsa.volume_scaling / 6553600.0F );

	set_mixer(false, ldB, rdB);
}

However, I'm concerned about some of the cross-fade/replay gain logic interfering. Can you see any issue with my approach? Is there a better way to achieve what I'm trying to?

Appreciate your thoughts!
Thanks, Dan.

I tried to use squeezelite (v1.9.1-1130) with stdout as output device which resulted in this output:

pi@raspberrypi:~/squeezelite $ ./squeezelite -o - -d all=debug
[00:33:25.637375] stream_init:294 init stream
[00:33:25.638048] stream_init:295 streambuf size: 2097152
[00:33:25.641956] output_init_stdout:130 init output stdout
[00:33:25.642140] output_init_common:350 outputbuf size: 3528000
[00:33:25.642288] output_init_common:374 idle timeout: 0
ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM -
[00:33:25.649294] test_open:281 playback open error: No such file or directory
[00:33:25.649384] output_init_common:384 unable to open output device: -
pi@raspberrypi:~/squeezelite $

I think the problem may be that it's trying to open alsa in test_open() since it is called in output_init_common() even when using stdout.

Hi Ralph - I was running test for my airplay bridge and it was not working well when I only my bridges synchronized. As soon as I added a SB, it was fine. I did not find anything in my sync, but the log of command send by LMS was strange: a strmu immediately followed by a strmp.

I think this is because the STMl is now sent too early, even when the buffer threshold is not met. Upon receiving STMl, LMS sends an strmu and then it realized that the buffer has not been filled and try to pause the player and it becomes messy.

That only happens with the patch for short files, and the issue is that now an STML is sent when stream.disconnect is DISCONNECT_OK, which is always true, because stream.disconnect is not reset at the beginning of opening a new stream, only when the previous one ended. I think you have to test that the status.stream.state (before sending STMl)

(status.stream_state == DISCONNECT && stream.disconnect == DISCONNECT_OK)

So that, the test applies for sure to short file, where slimproto missed the HTTP_STREAMING state, but a file was acquired properly (status.stream.state is captured from stream.state at DISCONNECT only once, then stream.state is set to STOPPED but I think this is at the same time this STML shall be sent)

Hi Ralphy,

related to https://forums.slimdevices.com/showthread.php?97046-Announce-Squeezelite-a-small-headless-squeezeplay-emulator-for-linux-(alsa-only)/page338

Playing a faulty MP3 ends up in a crash using mad decoder:
debug.log

whereas playing with mpg decoder show only errors but does not crash:
debugmpg.log

I intend to package squeezelite for Fedora. I notice that the Debian Project have written a manual page for squeezelite which they include in their package. Would you be interested in including this file in this repository so that it can be easily shared between the Fedora and Debian packages? I would be glad to prepare a pull request if so.

Hi Ralph,

I maintain squeezelite in Debian, which is currently stuck on Adrian's 1.8 release. I'd like to switch to your fork, but it would be helpful if you could make releases that I can track: I would prefer to avoid having to import snapshots of the Git repo if possible.

Many thanks,
Chris

Recently the squeezelite client has begun to display the behavior of frequently going to 100% CPU usage from around 10% that it has when playback is normal.
This happens roughly every 5 seconds and then will last for 1 to 3 seconds. The rate at which this happens is not constant and may decrease to where I may listen to a whole track without it occurring, but then with the next track it will start again.

My system is:
Headless Arch Linux on x86 dual core AMD Turion processor server.
I use this AUR package: https://aur.archlinux.org/packages/squeezelite-git/
Both LMS and squeezelite are running on the same machine and this used to work without issue for a long time until now.
I use a very simple USB DAC attached to the machine.
I do not have pulse audio installed.

Other software like this dlna audio client (https://github.com/hzeller/gmrender-resurrect) work without issue.

My command line for starting Squeezelite looks like this:
/usr/bin/squeezelite -n Wohnzimmer -m abc -f /var/log/squeezelite.log -d all info -s localhost

Whenever the CPU spikes to 100% the squeezelite logs show this line:
[00:07:22.249536] output_thread:655 XRUN

i first ran into this issue a while ago and i can't recall exactly how i tracked it down months ago, but it's a very simple fix:

--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -405,6 +405,7 @@ static decode_state ff_decode(void) {
 
 		len = AVCODEC(ff, decode_audio4, ff->codecC, ff->frame, &got_frame, &pkt_c);
 		if (len < 0) {
+			ff->readbuf = NULL;
 			LOG_ERROR("avcodec_decode_audio4 error: %i %s", len, av__err2str(len));
 			return DECODE_RUNNING;
 		}

without that, seeking in an wma file (compiled with -Wall -fPIC -O2 -march=native -DFFMPEG -DRESAMPLE -DLINKALL) crashes with SIGILL. fwiw it happens without resampling enabled so i think it's just an ffmpeg+musl(+arm?) specific thing. this is on alpine linux 3.8 armhf. this also happened in alpine 3.7 with a much older kernel, so i don't think it's related to that either. maybe just a musl thing?

here's the crash with decode=debug. the "error -22" doesn't seem to affect anything negatively.

[02:06:48.936561] ff_decode:408 avcodec_decode_audio4 error: -22 Invalid argument
[02:06:49.247809] ff_decode:408 avcodec_decode_audio4 error: -22 Invalid argument
[02:06:49.660335] ff_decode:408 avcodec_decode_audio4 error: -22 Invalid argument
[02:06:49.972177] ff_decode:408 avcodec_decode_audio4 error: -22 Invalid argument
[02:06:50.385652] ff_decode:408 avcodec_decode_audio4 error: -22 Invalid argument
[02:06:50.543862] decode_flush:229 decode flush
[02:06:50.564812] codec_open:257 codec open: 'w'
[02:06:50.565939] ff_open_wma:604 open wma chunking: 0 playstream: 0 metadatastream: 0
Illegal instruction

I pulled down the code and tried to compile under VS2015 and it appears that there are several library header files missing. If I have to compile these ahead of time and add the reference paths, would it be possible to get the links to the libraries used for Win32 compilation?

Hi Ralph, I've been trying to track down a problem for some time, this has happened with multiple versions of Squeezelite. I run SL on an Atheros AR9331 (MIPS) based device with a custom OpenWrt build:

https://wiki.openwrt.org/toh/tp-link/tl-mr3020

This runs in sync with another SL instance running on my LMS server. Occasionally, and at random periods, the MR3020 Squeezelite will stop playing and generate an irregular stutter which sounds like a note or two of the current song. I can easily recover by remotely logging in to the MR3020 and manually restarting Squeezelite. It seems to happen often after I've left the players paused overnight, but can happen in as little as 15 minutes of playing.

I set up logging and was able to capture debug for two separate failures. Around the failure time, I notice that "_output_frames" skips an inordinate number of frames.

Failure 1:

[22:32:24.308674] _output_frames:70 skip 352535 of 352535 frames
[22:32:25.007738] sendSTAT:182 STAT: STMt
[22:32:25.998458] process:512 strm
[22:32:25.998947] process_strm:267 strm command a
[22:32:25.999298] process_strm:313 skip ahead interval: 8500
[22:32:26.995036] process:512 strm
[22:32:26.995523] process_strm:267 strm command t
[22:32:26.995883] sendSTAT:182 STAT: STMt
[22:32:30.994361] process:512 strm
[22:32:30.994853] process_strm:267 strm command t
[22:32:30.995210] sendSTAT:182 STAT: STMt
[22:32:34.994357] process:512 strm
[22:32:34.994846] process_strm:267 strm command t
[22:32:34.995205] sendSTAT:182 STAT: STMt
[22:32:38.995791] process:512 strm
[22:32:38.996282] process_strm:267 strm command t
[22:32:38.996778] sendSTAT:182 STAT: STMt
[22:32:42.549536] _output_frames:70 skip 374850 of 374850 frames
[22:32:43.002954] sendSTAT:182 STAT: STMt
[22:32:43.003801] process:512 strm
[22:32:43.004513] process_strm:267 strm command t

Failure 2:

[08:57:46.181698] _output_frames:70 skip 417024 of 432797 frames
[08:57:47.006983] sendSTAT:182 STAT: STMt
[08:57:48.001203] process:512 strm
[08:57:48.001689] process_strm:267 strm command a
[08:57:48.002151] process_strm:313 skip ahead interval: 9338
[08:57:49.999632] process:512 strm
[08:57:50.000117] process_strm:267 strm command t
[08:57:50.002517] sendSTAT:182 STAT: STMt
[08:57:50.003287] process:512 strm
[08:57:50.003718] process_strm:267 strm command a
[08:57:50.004061] process_strm:313 skip ahead interval: 9339
[08:57:53.999234] process:512 strm
[08:57:53.999724] process_strm:267 strm command t
[08:57:54.000074] sendSTAT:182 STAT: STMt
[08:57:58.003774] process:512 strm
[08:57:58.004266] process_strm:267 strm command t
[08:57:58.004619] sendSTAT:182 STAT: STMt
[08:58:01.999483] process:512 strm
[08:58:01.999971] process_strm:267 strm command t
[08:58:02.000324] sendSTAT:182 STAT: STMt
[08:58:04.400775] _output_frames:70 skip 411849 of 411849 frames

At all other times, the _output_frames skip value is between 1000-3000 frames.

Any ideas about what might be happening?

My failure sounds very similar to this reported back in 2013:

http://forums.slimdevices.com/showthread.php?99916-workaround-for-pluginplayer-plays-quot-machingunsound-when-was-idle-some-time

That guy created a workaround script, restarting Squeezelite when remaining playtime gets stuck. But I'd rather figure out how to avoid the problem altogether.

Thanks for any help you can provide! (I attached full debug for both the failures, just in case.)
mr3020-squeezelite-fail.zip

BL

Can somebody confirm squeezelite working with output device pulseaudio?

If I select the Default Audio Device (in my case sysdefault:CARD=sndrpihifiberry) all is working very well, but as soon as I try to listen to the music over pulseaudio there is so much stuttering that I can't even identify that it's music, what's coming out of the speakers...

Here's the log entries of squeezelite and pulseaudio:

Sound (=Stuttering) starts after:
[18:42:26.227711] set_volume:229 setting internal gain left: 6656 right: 6656
And in pulseaudio-log I can see multiple "Implicit underrun of 'ALSA Playback'"

Please see squeezelite.log and pulseaudio.log
pulseaudio.txt
squeezelite.txt

Maybe someone has a clue for me how to get squeezelite working with pulseaudio?

Squeezelite uses function avcodec_decode_audio4 which is deprecated in recent ffmpeg versions. Compiling squeezelite against a recent ffmpeg version causes warnings and eventually I expect the compilation to fail if the function is completely dropped from ffmpeg.

Hi,

I'm trying to set the mixer for volume control wit the '-V" flag, but squeezelite is not able to use my device, this is what I did:

1. Show available mixer device

/usr/local/bin/squeezelite -L
Volume controls for default
DIYINHK USB Audio 2.0 Output Playback Volum
DIYINHK USB Audio 2.0 Output Playback Volum,1

2. Use one of the above as mixer for squeezelite

/usr/local/bin/squeezelite -n "living" -o front:CARD=D20,DEV=0 -a 80:4:32:1: -C 15 -V "DIYINHK USB Audio 2.0 Output Playback Volum"
[16:06:29.174832] mixer_init_alsa:869 attach error: No such file or directory
[16:06:29.175083] output_init_alsa:989 Initialization of mixer failed, reverting to software volume

3. Verify the mixer exists with alsa tools

amixer scontrols
Simple mixer control 'DIYINHK Internal Clock Validity',0
Simple mixer control 'DIYINHK USB Audio 2.0 Output Playback Switc',0
Simple mixer control 'DIYINHK USB Audio 2.0 Output Playback Switc',1
Simple mixer control 'DIYINHK USB Audio 2.0 Output Playback Volum',0
Simple mixer control 'DIYINHK USB Audio 2.0 Output Playback Volum',1

I have no idea how to further debug (debug flags didn't show any interesting other than the above). I've applied the above procedure to another player with a different sound-card and it works without a problem.

Could the name of the mixer be a problem (given it's truncated)??

##############################################################
Platform (piCoreplayer 4.1.0):

uname -a
Linux living 4.14.81-pcpCore_v7 #1 SMP Thu Nov 15 23:00:48 EST 2018 armv7l GNU/Linux

I receive this message: "process:530 unhandled vers." I am trying to install on a Windows 10 Enterprise machine (Version 1703, OS Build 15063.540).

Hello Ralph,

I'm using the newest squeezelite binary on a raspberry pi 2B with raspbian stretch and pulseaudio installed.
In previous versions of squeezelite (where there was the option "-o pulse") I could use several sources to play simultaneously on the pulseaudio-default-sink.

Now I get the following error if I try to connect to a bluetooth source while squeezelite is running:
[alsa-sink-HifiBerry AMP HiFi tas5713-hifi-0] alsa-sink.c: Error opening PCM device hw:0: Das Gerät oder die Ressource ist belegt

Do you know what I can do, to make it work again simultaneously?
Thanks, David

I was wondering if there was a code hook somewhere to add the ability to run a script when an on/off message is received from LMS?

Great piece of code BTW, very solid.

-Chris

I know that this issue was already raised two years ago in #29 but I would like to ask again for an official tag on github. Indeed, I would like to use your fork in buildroot and a tag would be nicer than a git commit. Especially, wikipedia (https://en.wikipedia.org/wiki/Squeezelite) specifies that current version is 1.9.0 and has been released on September 1st 2018 so it would be nice to have a tag for this release.